bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword

[Philip Kaludercic <philipk@posteo.net>]

No Wayman <iarchivedmywholelife@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> The issue was that I didn't see the bug report, due to the
>> "wishlist"
>> status (I believe you should have seen my other message).  The best
>> practice on mailing lists is to include people you think can provide
>> input, as I did with Tony.  If you have any further questions
>> regarding
>> package-vc, feel free to add a
>>
>>  X-Debbugs-CC: Philip Kaludercic <philipk@posteo.net>
>>
>> header, to make sure that I get notified.  I believe this kind of a
>> convention is something that GitHub-Style issue trackers also have
>> when
>> adding a @... to a message.
>
> Clunky. A point in favor of moving to some sort of forge which can
> improve upon that process.

We can't change that here; I just want you to know what you can do
within the existing structures to improve communication.

> Odd to me that whatever you're viewing the list with would exclude
> feature requests by default, too.

I use the "debbugs" package, and was surprised as well.

>>>> :ensure could accept:
>>>>
>>>> - nil: do not attempt to install anything
>>>> - t: attempt to install via the user's chosen default package
>>>> manager - a symbol name: install package matching that symbol name
>>>> with   default package manager
>>>> - a recipe spec: install via a forge capable package manager using
>>>> that package recipe. 
>>
>> But that would be incompatible with package-vc, as the default
>> installation remains (and should remain) tarballs.  Most of the
>> time,
>> you don't need to give any package specification when installing a
>> package, as they are provided by ELPA servers.
>
> Okay, then allow :ensure to take `t` meaning, "install the tarball"
> and `:vc` as a special case to use package-vc.el. e.g.
>
> (use-package example :ensure :vc) ;;install via package-vc.

Doesn't this go against your suggestion to have a uniform interface?
As we mentioned previously, :vc t can do this as well, without the
need to handle special values.

>> But generally speaking, the potential for confusion between
>> ELPA-style
>> package specifications and MELPA-style package recipes just sounds
>> like
>> something that has a lot of potential for confusion.
>
> Using the same interface would encourage compatibility in the recipe
> format
> Each package manager needn't support everything the others do, but it
> would make sense for them to support the most commonly used
> keywords. Also, most package authors do not include complex package
> recipes in their README's for installation instructions.

FWIW I am not a fan of having package authors recommending the usage of
package-vc, unless the user is interested in contributing patches.  The
ideal usage is just to re-use the package specifications provided by the
ELPA server, without having to make up something yourself.

>>>> It's not that complicated.
>>>> If anything, it would encourage package-manager authors to support
>>>> a basic subset of keywords for the package recipe spec, increasing
>>>> cross-compatibility for package recipes.
>>>
>>> Ah, I think I have a better idea of what you're trying to do now.
>>> Essentially, provide a totally generic interface for :ensure and
>>> then
>>> let people decide via use-package-ensure-function which package
>>> manager
>>> they actually want to use? Honestly, that sounds quite reasonable
>>> to me.
>>> One would have to make sure that certain edge cases are handled
>>> (like
>>> somehow preserving a version of :vc t and keeping the current
>>> functionality of :ensure in tact) but other than that I see no
>>> reason
>>> why something like this shouldn't be done.
>
> Yes, that's the general idea.
>
>> Wouldn't it make sense to extend the :vc keyword to support
>> alternative
>> package managers, instead of overloading :ensure?
>
> Makes less sense to do it that way.
> :ensure is/was already the interface by which people ensure a package
> is installed.
> Let's say someone implements another tarball based elisp package
> manager.
> Does it make more sense to specify they'd like to use that via a :vc
> (version control) keyword or :ensure? For me, the latter is clearly
> the correct choice.
>
> As Tony mentioned use-package already has
> `use-package-ensure-function' which was intended to facilitate
> something like this. It's documentation also mentions:
>
>> It is up to the function to decide on the semantics of the various
>> values for ‘:ensure’.
>
> The only potential for confusion is if a user decides they'd like to
> use multiple package managers at once, but that's a use-case which can
> cause confusion sans use-package, too.

Hmm, I get this point, but I don't see a neat and safe way to extend
:ensure.  And we have to keep in mind, that use-package was originally
made for package.el, and it was retrofitted to support other package
managers later on.  When considering this context, I think that
privileging built-in functionality like package-vc is acceptable.

>>> Just to make sure: in practice, the only package managers
>>> that—right
>>> now—support this schema are package.el (by means of :vc) and
>>> elpaca,
>>> right?
>>
>> To my knowledge, the only three package managers that have
>> use-package
>> integration are package.el, straight and elpaca (though I don't know
>> how
>> it looks like in the latter two cases).
>
> It looks like there is a package for Quelpa use-package integration
> which went the route of adding
> yet-another-keyword-that-is-basically-ensure:
>
> https://github.com/quelpa/quelpa-use-package
>
> They only advertise MELPA recipe compatibility. (Considering the
> number of MELPA recipes VS NON/GNU ELPA recipes, it would probably be
> less of a chore if GNU strove for compatibility with that format, too,
> but that's a separate issue).

FWIW package-vc uses the same package specification format as
elpa-admin, with the explicit intention of making it easier to
contribute these specifications to elpa.git/nongnu.git.

> I didn't find anything similar for borg or el-get.
>
>> My understanding is that "No Wayman" is Nicholas Vollmer
>> (https://github.com/progfolio), the
>> maintainer of the latter two?
>
> Correct. I'm the sole author of Elpaca and co-maintain straight.el
> with its original author.
>
>> If so, then I think we are in a wonderful position to propose that
>> Straight should add :url as an alias for :repo, which could make
>> this
>> more uniform -- that is if we actually want to take this path.
>
> My opinion on a standard elisp package recipe format is to keep
> keywords as general and few as possible. I'd like to eventually remove
> some keywords in Elpaca which were only added for straight.el
> compatibility. For example, :pre-build, :post-build, which are just
> special cases of :build.
>
> We have thousands of recipes "in the wild", mostly in MELPA's flavor,
> which should have been studied prior to adding more
> keywords. Specifically, Emacs should reconsider the :make and
> :shell-command keywords, which are too specific. :build is more
> generic and the semantics can be determined by the package manager.

Again, here we just re-use what ELPA-admin provides.  Both keywords are
used by ELPA packages, so we need to support them as well.

Overall I am not that convinced that there is a worthwhile advantage in
trying to unify these keywords.  I don't understand why package authors
feel the need to specify separate installation instructions for
different packages to begin with, so I am lacking the motivation behind
the problem to begin with.

-- 
	Philip Kaludercic on peregrine