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:

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

No. The :ensure keyword is the interface.
The semantics can vary depending on the package manager, though 
most cases won't in practice.
For example, I would just teach Elpaca and straight to consider 
:ensure :vc to mean the same as :ensure t.

> As we mentioned previously, :vc t can do this as well, without 
> the
> need to handle special values.

:vc *is* the special value.

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

There are many recipes which do exactly what you say, but they 
need to duplicate that info for less-experienced users. e.g.

(use-package example
  ;; uncomment one of the following to install with your package 
  manager of choice
  ;; :ensure t
  ;; :vc t
  ;; :straight t
  ;; :quelpa t
  )

Users also have to find and edit every use-package declaration 
which makes of use of such keywords if they decide to use a 
different package manager. Under my proposal they would not need 
to do as much work.
 
> Hmm, I get this point, but I don't see a neat and safe way to 
> extend :ensure.

The same way any other package manager would extend it.
The semantics I proposed above seem to cover all cases in use for 
other source-based package managers. Is there something special 
package-vc needs that they do not?

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

That was a wise decision. Otherwise it would be a leakier 
abstraction than it needs to be.
Built-in functionality loses no privilege by making the interface 
more consistent and flexible, though.
 
> Overall I am not that convinced that there is a worthwhile 
> advantage
> in trying to unify these keywords.

Fair enough. I've laid out my arguments.
My bike-shedding budget is near nil these days, so I'll retreat.

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

A few reasons that come to mind:
Not all packages are hosted on ELPAs.
Often people want to share a package *before* it goes through an 
ELPA's review process in hopes of gaining early testers.
Not all users use package.el.