Re: Objed maintenance

[Amy Grinn <grinn.amy@gmail.com>]

Philip Kaludercic <philipk@posteo.net> writes:

> Amy Grinn <grinn.amy@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>
>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>
>>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>>
>>>>>> Philip Kaludercic <philipk@posteo.net> writes:
>>>>>>
>>>>>>> Amy Grinn <grinn.amy@gmail.com> writes:
>>>>>>>
>>>>>>>> Philip, I am using an unpublished dependency called key-game,
>>>>>>>> which I wrote, which I thought might be useful for other modal
>>>>>>>> editing packages, or for large packages like gnus.  Anyways I
>>>>>>>> will try to submit that package for publishing on GNU ELPA
>>>>>>>> before
>>>>>>>> objed is updated.
>>>>>>>
>>>>>>> That sounds good, just inferring from the name it sounds like
>>>>>>> wizard or training program?  Is this going to be a hard
>>>>>>> dependency
>>>>>>> or a weak one?
>>>>>>
>>>>>> Yes, it's a utility package to help create key-based or
>>>>>> command-based tutorial games.  It's not a user-facing package,
>>>>>> similar to boxy; I wouldn't want users to have to install it
>>>>>> explicitly.  To answer a potential followup, I also wouldn't
>>>>>> want
>>>>>> to split up the objed tutorial game into a separate package.
>>>>>> That
>>>>>> would hinder discoverability and make the installation of objed
>>>>>> more complex.  All that to say I believe key-game will be a hard
>>>>>> dependency.
>>>>>
>>>>> That is a pity.  I try to advocate for minimising dependencies,
>>>>> especially if these aren't required for the core functionality of
>>>>> a
>>>>> package.  I don't know how your package is designed, but couldn't
>>>>> you have a command like M-x objed-tutorial that reports an error
>>>>> if
>>>>> the package is not installed (or proposes to install it)?  FWIW I
>>>>> don't think having a separate package is a good idea either --
>>>>> too
>>>>> much noise in the package list.
>>>>
>>>> Practically, the entrypoint for the objed tutorial game is a
>>>> key-game
>>>> macro call, so it would be difficult to rewire.  Moreover, this
>>>> would
>>>> cause a similar issue in all other packages which might use
>>>> key-game.
>>>> This implies much more boilerplate which must be maintained
>>>> separately in all those packages.
>>>>
>>>> I see your point that the tutorial is not *the* core feature of
>>>> objed, but in my opinion it is *a* core part, and one that is more
>>>> likely to be invoked by new users.  I don't want to put up
>>>> roadblocks
>>>> for them.  I think peer dependencies can be useful for extending a
>>>> package, and objed already has such a dependency with avy, but
>>>> this
>>>> seems like an unnecessary installation step instead.
>>>>
>>>> I'm not as experienced with ELPA, so I would like to know more
>>>> about
>>>> the thought process behind discouraging direct dependencies.  But
>>>> again, I don't think key-game has any intrinsic features which an
>>>> end
>>>> user may want separate and apart from its use in other packages,
>>>> and
>>>> I would find it odd to suggest users add it to their selected
>>>> packages.
>>>
>>> Abstractly: My advice is my advice, it is inherently biased.  I
>>> take
>>> that position, because of my experience, which is why I refuse to
>>> install packages with more than 1-~2 transitive dependencies (I was
>>> recently once again shocked by "ement").  As everything I say that
>>> isn't part of the ELPA rules, you can ignore it if you think you
>>> know
>>> better.  My motivation to help with ELPA is rooted in my own
>>> interest
>>> to have good packages, given my own understanding of what makes
>>> packages good.
>>>
>>> Concretely: I don't know how key-game looks like, so I cannot
>>> really
>>> say if it makes sense or not.  I had something in mind like a
>>> generic
>>> wizard framework, where you'd M-x key-game, then get prompted what
>>> game to play (as defined by whatever package provides a game) and
>>> then
>>> it would play that game.
>>
>> That's an interesting idea, kind of like man pages except for
>> tutorial
>> games.  Centralizing the entrypoint for all key games is not exactly
>> the
>> direction I took though, in the current implementation each package
>> is
>> responsible for creating a separate entrypoint.
>
> Right, I recall there was a discussion on creating a configuration
> wizard a few years back, and I'd imagine that it might look something
> like that as well.
>
>> I'll have to give it some more thought but I have a few concerns
>> already.  It probably doesn't address the boilerplate code issue I
>> brought up but more importantly it seems like a dual dependency:
>> objed-game requires key-game for its implementation and key-game
>> requires objed-game to register itself as a valid game.  If only one
>> of
>> the packages is loaded it would necessarily load the other I think?
>> Currently, the command objed-game resides in a separate file which
>> is
>> autoloaded (along with key-game) IFF a user invokes it.
>
> Why not just wrap it in a with-eval-after-load inside of objed-game?

That is a possibility, but wouldn't that make the key-game command very
slow the first time?  If a dozen packages implement key-games, they will
all be loaded at the same time.

> I am not familiar with the boiler-plate code (have you sent me the
> code and did I just miss it?)

To circle back, the discussion was about making key-game an optional
dependency.  So each package which implements a key game must have the
same boilerplate code that asks the user to install key-game and then
loads the full implementation.

> but if your input is just data, then you could add it to a list that
> key-game queries.

But key-game may not have been installed, so this would need to be a
with-eval-after-load situation as well.  And in order to make objed-game
visible to key-game even in the situation where objed hasn't been
loaded, the form must also be autoloaded.

>> When you have the time, I would like to know if you have a specific
>> autoload/dependency scheme in mind and if there are any similar
>> packages
>> already in ELPA which act as a centralized interface for interacting
>> with other packages.
>
> Perhaps the built-in VC package?  My autocrypt package is also built
> up
> in a way that would support this kind of usage, but these tackle
> different issues.

VC can always just be required by its dependents without installing
anything, so I don't think that is a particularly helpful example to me.
With autocrypt I see it has the ability to be extended but I couldn't
find any actual extension packages.  Nevertheless, if an autocrypt
extension was submitted to GNU ELPA, would you also suggest the author
not rely directly on autocrypt?

...

I understand and share your concern about packages like ement.
Particularly having a dependency like taxy-magit-section, which has no
real semantic meaning and has dependencies of its own which have their
OWN dependencies.  Since key-game will be the first dependency of objed,
has no dependencies of its own, and it's clear what the package does, I
don't think this is a directly comparable situation.

My overarching concern with your suggestions so far is that it would
complicate the dependency structure and make it more difficult to
develop and maintain key-game implementations.  That is the exact
opposite of the purpose of key-game, which is meant to simplify the
development of key based tutorial games.

I appreciate your time and thoughts but I think I'm going to keep the
dependency scheme as it is now: key-game will have no knowledge of where
it is being used and each implementation will depend directly on it.

-- 
Best,

Amy