unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Tony Zorman via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Philip Kaludercic <philipk@posteo.net>,
	No Wayman <iarchivedmywholelife@gmail.com>
Cc: 69410@debbugs.gnu.org
Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword
Date: Mon, 01 Jul 2024 15:37:01 +0200	[thread overview]
Message-ID: <87wmm55j42.fsf@hyperspace> (raw)
In-Reply-To: <87jzi6lnjp.fsf@posteo.net>

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





  reply	other threads:[~2024-07-01 13:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-26 16:06 bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword No Wayman
2024-06-30 10:42 ` Philip Kaludercic
2024-07-01 13:37   ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-07-01 19:57     ` Philip Kaludercic
2024-07-03 19:56       ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]     ` <87zfr15hqj.fsf@gmail.com>
2024-07-01 14:28       ` No Wayman
2024-07-03 20:34         ` Philip Kaludercic
2024-07-08 12:12           ` No Wayman
2024-07-08 15:52             ` Philip Kaludercic
2024-07-09  2:30               ` No Wayman
2024-07-09  9:02                 ` Philip Kaludercic
2024-07-09  9:56                   ` No Wayman
2024-07-09  7:34               ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-09  8:26                 ` Philip Kaludercic
2024-07-03 19:51       ` Tony Zorman via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wmm55j42.fsf@hyperspace \
    --to=bug-gnu-emacs@gnu.org \
    --cc=69410@debbugs.gnu.org \
    --cc=iarchivedmywholelife@gmail.com \
    --cc=philipk@posteo.net \
    --cc=soliditsallgood@mailbox.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).