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

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

[No Wayman]

I think it would be cleaner to allow use-package's :ensure keyword 
to accept the arguments the :vc keyword currently does. e.g.

;; Install EXAMPLE package from ELPA archive
(use-package example :ensure t)

;; Install EXAMPLE package from source
(use-package example :ensure (:url 
"https://www.forge.com/maintainer/example"))

My reasoning is that this has greater potential to work across 
multiple package managers.
Instead of each package manager adding their own use-package 
keyword (e.g. :vc, :straight, :elpaca), they can all interpret the 
:ensure keyword's value. It would make things simpler for package 
maintainers offering example declarations and users switching 
between package managers.

Thoughts? 

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:

> I think it would be cleaner to allow use-package's :ensure keyword to
> accept the arguments the :vc keyword currently does. e.g.
>
> ;; Install EXAMPLE package from ELPA archive
> (use-package example :ensure t)
>
> ;; Install EXAMPLE package from source
> (use-package example :ensure (:url
> "https://www.forge.com/maintainer/example"))
>
> My reasoning is that this has greater potential to work across
> multiple package managers.
> Instead of each package manager adding their own use-package keyword
> (e.g. :vc, :straight, :elpaca), they can all interpret the :ensure
> keyword's value. It would make things simpler for package maintainers
> offering example declarations and users switching between package
> managers.

I am adding Tony to the CCs, as he implemented the :vc keyword to see if
he has anything to comment (generally it is good to add a X-Debbugs-CC
header, mentioning specific maintainers or people involved in a feature
when submitting a bug).

My own take is that setting aside timing issues and the fact that the
Emacs 30 branch has been cut, ...

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

- I am not a fan of encouraging the usage of VC packages, since
  version control brings in some complications that tarballs avoid
  (especially when it comes to upgrading).

- If I try to evaluate the expression you suggest I get a warning:

    ⛔ Error (use-package): Failed to parse package example:
    use-package: :ensure wants an optional package name (an unquoted
    symbol name), or (<symbol> :pin <string>)

  and I am wondering, if there is a potentially ambiguous conflict
  between your suggestion and the (<symbol> :pin <string>) case, that
  might trigger an edge case in some configuration.

> Thoughts? 

-- 
	Philip Kaludercic on peregrine

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

[Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Sun, Jun 30 2024 10:42, Philip Kaludercic wrote:
> No Wayman <iarchivedmywholelife@gmail.com> writes:
>
>> I think it would be cleaner to allow use-package's :ensure keyword to
>> accept the arguments the :vc keyword currently does. e.g.
>>
>> ;; Install EXAMPLE package from ELPA archive
>> (use-package example :ensure t)
>>
>> ;; Install EXAMPLE package from source
>> (use-package example :ensure (:url
>> "https://www.forge.com/maintainer/example"))
>>
>> My reasoning is that this has greater potential to work across
>> multiple package managers.
>> Instead of each package manager adding their own use-package keyword
>> (e.g. :vc, :straight, :elpaca), they can all interpret the :ensure
>> keyword's value. It would make things simpler for package maintainers
>> offering example declarations and users switching between package
>> managers.
>
> I am adding Tony to the CCs, as he implemented the :vc keyword to see if
> he has anything to comment (generally it is good to add a X-Debbugs-CC
> header, mentioning specific maintainers or people involved in a feature
> when submitting a bug).

Thanks. To be honest, I'm not a big fan of trying to cram everything
into :ensure. Implementation wise, I feel like it would make things much
messier than they are now—especially if the final goal is to maybe
extend this to other package managers. 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.

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 especially true since use-package-always-ensure exists (and many
people use it) so one would just have to write

  (use-package example
    :vc (:url "https://www.forge.com/maintainer/example"))

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.

> My own take is that setting aside timing issues and the fact that the
> Emacs 30 branch has been cut, ...
>
> - 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 …).

  Tony

-- 
Tony Zorman | https://tony-zorman.com

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

[No Wayman]

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

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

[Philip Kaludercic]

Tony Zorman <soliditsallgood@mailbox.org> writes:

> On Sun, Jun 30 2024 10:42, Philip Kaludercic wrote:
>> No Wayman <iarchivedmywholelife@gmail.com> writes:
>>
>>> I think it would be cleaner to allow use-package's :ensure keyword to
>>> accept the arguments the :vc keyword currently does. e.g.
>>>
>>> ;; Install EXAMPLE package from ELPA archive
>>> (use-package example :ensure t)
>>>
>>> ;; Install EXAMPLE package from source
>>> (use-package example :ensure (:url
>>> "https://www.forge.com/maintainer/example"))
>>>
>>> My reasoning is that this has greater potential to work across
>>> multiple package managers.
>>> Instead of each package manager adding their own use-package keyword
>>> (e.g. :vc, :straight, :elpaca), they can all interpret the :ensure
>>> keyword's value. It would make things simpler for package maintainers
>>> offering example declarations and users switching between package
>>> managers.
>>
>> I am adding Tony to the CCs, as he implemented the :vc keyword to see if
>> he has anything to comment (generally it is good to add a X-Debbugs-CC
>> header, mentioning specific maintainers or people involved in a feature
>> when submitting a bug).
>
> Thanks. To be honest, I'm not a big fan of trying to cram everything
> into :ensure. Implementation wise, I feel like it would make things much
> messier than they are now—especially if the final goal is to maybe
> extend this to other package managers. 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.
>
> 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"))

BTW Does it ever make sense to give a :vc keyword without :ensure t or
enabling `use-package-always-ensure'?

> This is especially true since use-package-always-ensure exists (and many
> people use it) so one would just have to write
>
>   (use-package example
>     :vc (:url "https://www.forge.com/maintainer/example"))
>
> 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.

1+

>> My own take is that setting aside timing issues and the fact that the
>> Emacs 30 branch has been cut, ...
>>
>> - 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 …).

I am not sure what you mean here?

>   Tony

-- 
	Philip Kaludercic on peregrine

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

[Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

  Tony

-- 
Tony Zorman | https://tony-zorman.com

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

[Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On Mon, Jul 01 2024 19:57, Philip Kaludercic wrote:
> Tony Zorman <soliditsallgood@mailbox.org> writes:
>
> [… 41 lines elided …]
>
>>   (use-package example
>>     :ensure t
>>     :vc (:url "https://www.forge.com/maintainer/example"))
>
> BTW Does it ever make sense to give a :vc keyword without :ensure t or
> enabling `use-package-always-ensure'?

Ah, this is a good point (which I had completely forgotten!). Since
package-vc.el is the only backend that :vc needs to support right now,
we actually completely circumvent :ensure (which by default just calls
out to the package archives). When :vc is present then whatever argument
is given to :ensure is disregarded.

  Tony

-- 
Tony Zorman | https://tony-zorman.com

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