Re: Objed maintenance

[Amy Grinn]

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.

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.

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.

-- 
Best,

Amy