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

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

[No Wayman]

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.

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:

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

We can't change that here; I just want you to know what you can do
within the existing structures to improve communication.

> Odd to me that whatever you're viewing the list with would exclude
> feature requests by default, too.

I use the "debbugs" package, and was surprised as well.

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

Doesn't this go against your suggestion to have a uniform interface?
As we mentioned previously, :vc t can do this as well, without the
need to handle special values.

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

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.

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

Hmm, I get this point, but I don't see a neat and safe way to extend
:ensure.  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.

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

FWIW package-vc uses the same package specification format as
elpa-admin, with the explicit intention of making it easier to
contribute these specifications to elpa.git/nongnu.git.

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

Again, here we just re-use what ELPA-admin provides.  Both keywords are
used by ELPA packages, so we need to support them as well.

Overall I am not that convinced that there is a worthwhile advantage in
trying to unify these keywords.  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.

-- 
	Philip Kaludercic on peregrine

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

[No Wayman]

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.

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

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

Philip Kaludercic <philipk@posteo.net> writes:

> No Wayman <iarchivedmywholelife@gmail.com> writes:

>> Odd to me that whatever you're viewing the list with would exclude
>> feature requests by default, too.

Really? On the debbugs.gnu.org web page, wishlist bugs are listed.

> I use the "debbugs" package, and was surprised as well.

Really? It is up to you to configure your preferences. I have heard of
people who did profit from reading the respective info manual.

Best regards, Michael.

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

[Philip Kaludercic]

Michael Albinus <michael.albinus@gmx.de> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> No Wayman <iarchivedmywholelife@gmail.com> writes:
>
>>> Odd to me that whatever you're viewing the list with would exclude
>>> feature requests by default, too.
>
> Really? On the debbugs.gnu.org web page, wishlist bugs are listed.
>
>> I use the "debbugs" package, and was surprised as well.
>
> Really? It is up to you to configure your preferences. I have heard of
> people who did profit from reading the respective info manual.

That is true, the `debbugs-gnu-default-severities' user option just
doesn't list wishlist by default, and I always use the default
severities, and never noticed that I was missing out on something. 

> Best regards, Michael.

-- 
	Philip Kaludercic on peregrine

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:


[...]

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

Yes?  My point is that I think it would be better to avoid a 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.

My point is that a less experienced user doesn't really have to use
package-vc in the first place.

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

As a point of clarification, are you suggesting to drop the :vc keyword,
or just to extend :ensure?  Specifically so that it handles the package
name ":vc" as an instruction to install the package from source?

[...]

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

FWIW, if someone proposes a patch, I'd be glad to review it from the
package-vc side of things.  As I do not use use-package or the :vc
keyword, I'll let others comment on that.

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

That is an argument for supporting the installation of packages from
source, not for packages to have to give instructions on how to install
a package (which as you say, are the same most of the time). 

-- 
	Philip Kaludercic on peregrine

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

[No Wayman]

Philip Kaludercic <philipk@posteo.net> writes:

>> :vc *is* the special value.
>
> Yes?  My point is that I think it would be better to avoid a 
> special
> value?

I meant it is a special value at the top-level of a use-package 
statement, too.
Even "more special" in that case.
 
>> There are many recipes which do exactly what you say, but they 
>> need to
>> duplicate that info for less-experienced users. e.g.
>
> My point is that a less experienced user doesn't really have to 
> use
> package-vc in the first place.

I understand your preference for package.el + tarballs, but not 
everyone shares that preference.
 
> As a point of clarification, are you suggesting to drop the :vc 
> keyword,
> or just to extend :ensure?  Specifically so that it handles the 
> package
> name ":vc" as an instruction to install the package from source?

Drop :vc; extend :ensure.
There is no package named ":vc" and, in practice,
there are no packages (out of the roughly 7 thousand I've seen) 
that make use of a keyword as their prefix.

>>> 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.
>
> FWIW, if someone proposes a patch, I'd be glad to review it from 
> the
> package-vc side of things.  As I do not use use-package or the 
> :vc
> keyword, I'll let others comment on that.

I'll let someone else spend the effort there (and on the ensuing 
discussion).

> That is an argument for supporting the installation of packages 
> from
> source, not for packages to have to give instructions on how to 
> install
> a package (which as you say, are the same most of the time). 

As long as there are many top-level use-package keywords which do 
essentially the same thing as :ensure, package authors will want 
to do this to cater to as many users as possible.
The "value" of the keyword is the same most of the time (a simple 
`t` or the feature name).
The current situation demands that the *keyword* is always 
different.

We're talking in circles now, though.