From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic 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: Wed, 03 Jul 2024 20:34:52 +0000 Message-ID: <87wmm21afn.fsf@posteo.net> References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <87zfr15hqj.fsf@gmail.com> <87v81p5gpp.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2176"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Tony Zorman , 69410@debbugs.gnu.org To: No Wayman Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 03 22:36:07 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 1sP6hz-0000Je-6t for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 03 Jul 2024 22:36:07 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sP6hu-0004Bp-CO; Wed, 03 Jul 2024 16:36:02 -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 1sP6hs-0004BI-BI for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2024 16:36:00 -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 1sP6hs-0005jo-2f for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2024 16:36:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sP6hu-0004ZV-09 for bug-gnu-emacs@gnu.org; Wed, 03 Jul 2024 16:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Jul 2024 20:36:01 +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.172003891217491 (code B ref 69410); Wed, 03 Jul 2024 20:36:01 +0000 Original-Received: (at 69410) by debbugs.gnu.org; 3 Jul 2024 20:35:12 +0000 Original-Received: from localhost ([127.0.0.1]:40786 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP6h5-0004Y2-8N for submit@debbugs.gnu.org; Wed, 03 Jul 2024 16:35:11 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:33861) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP6gx-0004XG-HU for 69410@debbugs.gnu.org; Wed, 03 Jul 2024 16:35:09 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 757F9240029 for <69410@debbugs.gnu.org>; Wed, 3 Jul 2024 22:34:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720038894; bh=K5ELi8ksjBR9ZQwJTge5+IERJrD+pl9BstVTgcDv0IQ=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=P/ha/LCzYzgWg80mf40OK/m/EJkkYpJL6yRjbksTLitKvrpuyssyMnFQAq8mGL6+g HAXNgd3xCmrmoEk//v+ww4M0XPWKoCjow8q/eEbT7T/NAhU8JuWUg8fyXf/iS59jVW M86ls0+4qWq8ECFHQigLGBvph3/+vkOVAbxrrBy/9quZlGZeXXqQErC7PvWXOX8qJQ 84SMUkNrm+7GBWp7mAtbh9yNxtx6o8XT9qFoOTyotRXEu99fpSrz+/WjYTx+P1x//B yPTWf+VOwp2YPYBeSwPrzLOobfC/UTibGdczaertIg7PubFbKPBxkDtvg+EETCQFIO xGIhhJU4sGwtA== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WDs312NgPz6tyG; Wed, 3 Jul 2024 22:34:53 +0200 (CEST) In-Reply-To: <87v81p5gpp.fsf@gmail.com> (No Wayman's message of "Mon, 01 Jul 2024 10:28:50 -0400") OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt 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:288336 Archived-At: No Wayman writes: > -------------------- Start of forwarded message > -------------------- > From: No Wayman > To: Tony Zorman [ 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.)=20 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 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 writes: > On Mon, Jul 01 2024 10:06, No Wayman wrote: > >> Tony Zorman 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=20 >> manager=20 >> - a symbol name: install package matching that symbol name with=20 >> default package manager >> - a recipe spec: install via a forge capable package manager 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 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=20 >> a basic subset of keywords for the package recipe spec, increasing=20 >> 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=20 >> package's README would look something like this: >> >>> (use-package example >>> :ensure t >>> ;; uncomment one of the following for your package manager=20 >>> 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=20 >> keyword, that's on them. > > Just to make sure: in practice, the only package managers that=E2=80=94ri= ght > now=E2=80=94support this schema are package.el (by means of :vc) and elpa= ca, > 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. --=20 Philip Kaludercic on peregrine