Package: emacs;
Reported by: No Wayman <iarchivedmywholelife <at> gmail.com>
Date: Mon, 26 Feb 2024 16:26:03 UTC
Severity: wishlist
Found in version 30.0.50
View this message in rfc822 format
From: No Wayman <iarchivedmywholelife <at> gmail.com> To: Philip Kaludercic <philipk <at> posteo.net> Cc: Tony Zorman <soliditsallgood <at> mailbox.org>, 69410 <at> 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, 08 Jul 2024 08:12:18 -0400
Philip Kaludercic <philipk <at> 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 <at> 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.