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

[No Wayman <iarchivedmywholelife@gmail.com>]

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.
Odd to me that whatever you're viewing the list with would exclude 
feature requests by default, too.
 
>>> :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.
 
> 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.
 
>>> 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.
 
>> 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).

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.