From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: No Wayman Newsgroups: gmane.emacs.bugs 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 Message-ID: <87h6d0xeu5.fsf@gmail.com> References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <87zfr15hqj.fsf@gmail.com> <87v81p5gpp.fsf@gmail.com> <87wmm21afn.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29193"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tony Zorman , 69410@debbugs.gnu.org To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jul 08 14:14:12 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sQnFy-0007Nq-L2 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Jul 2024 14:14:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sQnFo-0000iY-FS; Mon, 08 Jul 2024 08:14:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sQnFm-0000iK-VM for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 08:13:58 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sQnFm-0000c9-Ml for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 08:13:58 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sQnFq-0001pS-HO for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 08:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: No Wayman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Jul 2024 12:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs Original-Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.17204408216994 (code B ref 69410); Mon, 08 Jul 2024 12:14:02 +0000 Original-Received: (at 69410) by debbugs.gnu.org; 8 Jul 2024 12:13:41 +0000 Original-Received: from localhost ([127.0.0.1]:49858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQnFV-0001ok-2I for submit@debbugs.gnu.org; Mon, 08 Jul 2024 08:13:41 -0400 Original-Received: from mail-qv1-f46.google.com ([209.85.219.46]:57732) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQnFS-0001ob-JY for 69410@debbugs.gnu.org; Mon, 08 Jul 2024 08:13:39 -0400 Original-Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-6b5ec93f113so21012376d6.3 for <69410@debbugs.gnu.org>; Mon, 08 Jul 2024 05:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720440753; x=1721045553; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id :reply-to; bh=EgY0txcv3Sjl1L+dJoDyXodESNb/Beu3/k6vlMNBmO0=; b=Fm0PRzdTrz2WJ9ub+OlHBwiTUTLqw/Qj0nLhP5g7Bz5fgNPujZ96Yloo6qy4soMtxV uJg5Z8JEgI1Z8Y58OdD1GLye/8545XEnYWmCli1xU3n7F6ozrW78F+OJcMGmjou6nBhz t47gUw8LRvJSfI9hMSD7r16qA5bcascY13HTB3dcpa3Gh5dmpMQaVL2fcou5F4gn1TCv hFtxdLRQWy6tRs0r3kTXvXMBMMTN+rOj+U9RID6lzsxlZo72y889VKWxBSARYovTa6/P aMzhG7m1TTjRNSULzKcsr+DfcdapEi7LML9KfqrVdgVCc/WER599IE7URhfmOIWh52ni 3ujg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720440753; x=1721045553; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=EgY0txcv3Sjl1L+dJoDyXodESNb/Beu3/k6vlMNBmO0=; b=PiCuZ8oz7t3ANeN0B+9y+t7Wc7LgP6nk9lLtR672vl1P/3dd2dAboN6XjsCJU7UGRn ccsqsA0rMt6Bu0D4mHjBvDxPFGPyQLlj4Fu2PQq8IYazn3Q95em9U8s61xh78Hxx7b4j oJH5rKGEsGYncUWpdeqOavMov4giDArkSuJH0Qal+facPAGYgdcMn67FjUGoWjcI15J+ eM+dPqYZ+4hG41VtXeVRpiyt9ka3IWuvvFGkmTj6ndFhJgmHy4jIsmcjEEfX6u39x1Kb K6Ja9GgF7OB6u/ly3xPPmMKhYVgg1NCuedUnsTioEKeoITY050kbenZEvdYSukqIecPV ywSw== X-Gm-Message-State: AOJu0Yz/4r9KkqqhNaX7Ah78uVkghGkHOKEwfZRJz0KC4KF7+2QzyEMQ IhkTAtynAYwd3llU3wo1bXucnLx8ltyx8i1lexWYp7ICkBhyevEr X-Google-Smtp-Source: AGHT+IFAOyB9zdeAHkIF0eh9+KQsPzH8q2UtjQGysRhEd+0aNDBMVgoihHQKRjp9mkhUcn6QZ0iMNQ== X-Received: by 2002:ad4:5ce8:0:b0:6b5:2b33:5445 with SMTP id 6a1803df08f44-6b5ecfc6a8bmr172587586d6.25.1720440753121; Mon, 08 Jul 2024 05:12:33 -0700 (PDT) Original-Received: from laptop ([2601:84:847f:c697:e217:2894:4724:14f4]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b5f82080fbsm34861116d6.102.2024.07.08.05.12.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jul 2024 05:12:32 -0700 (PDT) In-Reply-To: <87wmm21afn.fsf@posteo.net> (Philip Kaludercic's message of "Wed, 03 Jul 2024 20:34:52 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:288588 Archived-At: Philip Kaludercic writes: > The issue was that I didn't see the bug report, due to the=20 > "wishlist" > status (I believe you should have seen my other message). The=20 > best > practice on mailing lists is to include people you think can=20 > provide > input, as I did with Tony. If you have any further questions=20 > regarding > package-vc, feel free to add a > > X-Debbugs-CC: Philip Kaludercic > > header, to make sure that I get notified. I believe this kind=20 > of a > convention is something that GitHub-Style issue trackers also=20 > have when > adding a @... to a message. Clunky. A point in favor of moving to some sort of forge which can=20 improve upon that process. Odd to me that whatever you're viewing the list with would exclude=20 feature requests by default, too. =20 >>> :ensure could accept: >>> >>> - nil: do not attempt to install anything >>> - t: attempt to install via the user's chosen default package=20 >>> manager=20 >>> - a symbol name: install package matching that symbol name=20 >>> with=20 >>> default package manager >>> - a recipe spec: install via a forge capable package manager=20 >>> using=20 >>> that package recipe.=20 > > But that would be incompatible with package-vc, as the default > installation remains (and should remain) tarballs. Most of the=20 > time, > you don't need to give any package specification when installing=20 > a > package, as they are provided by ELPA servers. Okay, then allow :ensure to take `t` meaning, "install the=20 tarball" and `:vc` as a special case to use package-vc.el. e.g. (use-package example :ensure :vc) ;;install via package-vc. =20 > But generally speaking, the potential for confusion between=20 > ELPA-style > package specifications and MELPA-style package recipes just=20 > sounds like > something that has a lot of potential for confusion. Using the same interface would encourage compatibility in the=20 recipe format Each package manager needn't support everything the others do, but=20 it would make sense for them to support the most commonly used=20 keywords. Also, most package authors do not include complex=20 package recipes in their README's for installation instructions. =20 >>> It's not that complicated. >>> If anything, it would encourage package-manager authors to=20 >>> support=20 >>> a basic subset of keywords for the package recipe spec,=20 >>> increasing=20 >>> cross-compatibility for package recipes. >> >> Ah, I think I have a better idea of what you're trying to do=20 >> now. >> Essentially, provide a totally generic interface for :ensure=20 >> and then >> let people decide via use-package-ensure-function which package=20 >> manager >> they actually want to use? Honestly, that sounds quite=20 >> reasonable to me. >> One would have to make sure that certain edge cases are handled=20 >> (like >> somehow preserving a version of :vc t and keeping the current >> functionality of :ensure in tact) but other than that I see no=20 >> 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=20 > 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=20 package is installed. Let's say someone implements another tarball based elisp package=20 manager. Does it make more sense to specify they'd like to use that via a=20 :vc (version control) keyword or :ensure? For me, the latter is=20 clearly the correct choice. As Tony mentioned use-package already has=20 `use-package-ensure-function' which was intended to=20 facilitate something like this. It's documentation also mentions: > It is up to the function to decide on the semantics of the=20 > various values for =E2=80=98:ensure=E2=80=99. The only potential for confusion is if a user decides they'd like=20 to use multiple package managers at once, but that's a use-case=20 which can cause confusion sans use-package, too. =20 >> Just to make sure: in practice, the only package managers=20 >> that=E2=80=94right >> now=E2=80=94support this schema are package.el (by means of :vc) and=20 >> elpaca, >> right? > > To my knowledge, the only three package managers that have=20 > use-package > integration are package.el, straight and elpaca (though I don't=20 > know how > it looks like in the latter two cases). It looks like there is a package for Quelpa use-package=20 integration which went the route of adding=20 yet-another-keyword-that-is-basically-ensure: https://github.com/quelpa/quelpa-use-package They only advertise MELPA recipe compatibility. (Considering the=20 number of MELPA recipes VS NON/GNU ELPA recipes, it would probably=20 be less of a chore if GNU strove for compatibility with that=20 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=20 > (https://github.com/progfolio), the > maintainer of the latter two? Correct. I'm the sole author of Elpaca and co-maintain straight.el=20 with its original author. > If so, then I think we are in a wonderful position to propose=20 > that > Straight should add :url as an alias for :repo, which could make=20 > 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=20 keywords as general and few as possible. I'd like to eventually=20 remove some keywords in Elpaca which were only added for=20 straight.el compatibility. For example, :pre-build, :post-build,=20 which are just special cases of :build. We have thousands of recipes "in the wild", mostly in MELPA's=20 flavor, which should have been studied prior to adding more=20 keywords.=20 Specifically, Emacs should reconsider the :make and :shell-command=20 keywords, which are too specific. :build is more generic and the=20 semantics can be determined by the package manager.