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

[No Wayman <iarchivedmywholelife@gmail.com>]

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

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. 

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.

> By the same thought, one might
> argue that something like :load-path should be inlined into 
> :ensure as
> well, which is not a good idea in my opinion.

No one is arguing that.
 
> In either case, I think that
>
>   (use-package example
>     :ensure (:url "https://www.forge.com/maintainer/example"))
>
> is not that much more verbose (or harder to adjust) than
>
>   (use-package example
>     :ensure t
>     :vc (:url "https://www.forge.com/maintainer/example"))

This is not what package authors provide in practice.
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.
 
> This is especially true since use-package-always-ensure exists 
> (and many
> people use it) so one would just have to write

It's not about the `:ensure t`, it's about every package manager 
requiring their own, separate interface to use-package, when they 
basically operate on the same data structure.

> Any kind of backwards compatibility with a hypothetical 
> :straight
> keyword would not work in either case, because :straight already 
> exists
> in straight.el and it has a completely different package 
> specification
> attached to it.

Not asking for this, either.
I'd like to see the `:straight` keyword go away.
Making that happen would be the burden of straight's maintainers 
(of which I am one).
 
>> 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 :vc keyword allows just passing t to download the package 
>> as
>>   specified in the ELPA archive.  I don't see an elegant away 
>>   to allow
>>   this using :ensure.
>
> Yes backwards compatibility might be a bit of a pain—especially 
> with a
> view on use-package-always-ensure—save having self-defeating 
> constructs
> like :ensure (:vc …).

It's evident there's little enthusiasm for the idea now, too.
That being the case, I'll relax the constraints on Elpaca's recipe 
format I placed in hopes of offering an easier switch between 
package managers for users.
Thanks for the input.
-------------------- End of forwarded message --------------------