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, 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.