Re: Objed maintenance

[Philip Kaludercic <philipk@posteo.net>]

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.

-- 
	Philip Kaludercic on peregrine