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

[Philip Kaludercic]

No Wayman <iarchivedmywholelife@gmail.com> writes:

> -------------------- Start of forwarded message
>                      --------------------
> From: No Wayman <iarchivedmywholelife@gmail.com>
> To: Tony Zorman <soliditsallgood@mailbox.org>

[ If you accidentally reply only to one person, it would be useful to CC
everyone involved when forwarding the message, or even better to resend
it, which most mail providers allow for a short while after the first
message was composed.  I usually edit my message locally, adding the
missing CCs and then use M-x gnus-summary-resend-message.  ]

> Subject: Re: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure
> to
> accept package spec instead of separate :vc keyword
> Date: Mon, 01 Jul 2024 10:06:44 -0400
>>> My own take is that setting aside timing issues and the fact that
>>> the
>>> Emacs 30 branch has been cut, ...
>
> I brought it up well before then, but nobody was interested/aware
> enough to reply.
> (Not the first time it's happened on these mailing lists, and a
> primary reason I seldom chime in.) 

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.

Tony Zorman <soliditsallgood@mailbox.org> writes:

> On Mon, Jul 01 2024 10:06, No Wayman wrote:
>
>> Tony Zorman <soliditsallgood@mailbox.org> writes:
>>
>>> Thanks. To be honest, I'm not a big fan of trying to cram everything
>>> into :ensure.
>>
>> I wouldn't describe it as "cramming everything into :ensure".
>> :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.

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.

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

Wouldn't it make sense to extend the :vc keyword to support alternative
package managers, instead of overloading :ensure?

>> Taking your example, the package installation section of a 
>> package's README would look something like this:
>>
>>>   (use-package example
>>>     :ensure t
>>>     ;; uncomment one of the following for your package manager 
>>>     of choice...
>>>     :vc (:url "https://www.forge.com/maintainer/example";)
>>>     :straight (:repo "https://www.forge.com/maintainer/example";)
>>>     :elpaca (:url "https://www.forge.com/maintainer/example";)
>>>     :some-other-package-manager (:url ...)
>>>     ;; and so on...
>>>    )
>>
>> Using my proposal:
>>
>>>   (use-package example
>>>     :ensure (:url "https://www.forge.com/maintainer/example";))
>>
>> If a package manager decides not to support the :url recipe 
>> keyword, that's on them.
>
> 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).  My understanding is that "No
Wayman" is Nicholas Vollmer (https://github.com/progfolio), the
maintainer of the latter two?  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.

-- 
        Philip Kaludercic on peregrine