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: Tue, 09 Jul 2024 09:02:03 +0000 Message-ID: <87frsjhras.fsf@posteo.net> References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <87zfr15hqj.fsf@gmail.com> <87v81p5gpp.fsf@gmail.com> <87wmm21afn.fsf@posteo.net> <87h6d0xeu5.fsf@gmail.com> <87plrnhoem.fsf@posteo.net> <87wmlvmh4w.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20995"; 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 Tue Jul 09 11:03:15 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 1sR6kl-0005BL-4S for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Jul 2024 11:03:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sR6kU-0004Xw-Sk; Tue, 09 Jul 2024 05:02:58 -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 1sR6kT-0004XJ-7m for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 05:02:57 -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 1sR6kS-0007D3-Uf for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 05:02:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sR6kY-00074v-9O for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2024 05:03: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: Tue, 09 Jul 2024 09:03: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.172051576327161 (code B ref 69410); Tue, 09 Jul 2024 09:03:02 +0000 Original-Received: (at 69410) by debbugs.gnu.org; 9 Jul 2024 09:02:43 +0000 Original-Received: from localhost ([127.0.0.1]:52130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR6kE-000740-TC for submit@debbugs.gnu.org; Tue, 09 Jul 2024 05:02:43 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:43331) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR6kC-00073m-UF for 69410@debbugs.gnu.org; Tue, 09 Jul 2024 05:02:42 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 1245C24002D for <69410@debbugs.gnu.org>; Tue, 9 Jul 2024 11:02:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720515748; bh=hGYRiR5eziCvGxRNZLE3EHFPkgpr//dfwLG1b0Fdpt0=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=Uv/T9xZEeCfg7qumFJc9fmhrqp7zNvmiA3OJ0ASVlVlzhNvabYLhlNbf7t4GJowKz CU7Tmr+cbPC83rlic+HiTD1Z09Qw8L4pLt0AHHP9urpWUIxfGiTNKjjProjBHsLl75 A3fVnt5yrfsVAvuJHvqeoHvo2cStJemMnJrpYJa+MhRo1NikxJNbsRK2H+houDJIm7 lNmwyBAOesaWjR90Q0G7rDn5IHAWDaaJVUlsMhYVJ9X5fgnAmV+xhasZtSrZFlwVSo mVPtfk1mT4Eu/8YYPtR0zIwLsBXl9T757dX5grOURoTunLVhSdT4Fz9WLRAAwNvszz ZMyQJcTctAeVw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WJFNq5DMXz9rxB; Tue, 9 Jul 2024 11:02:03 +0200 (CEST) In-Reply-To: <87wmlvmh4w.fsf@gmail.com> (No Wayman's message of "Mon, 08 Jul 2024 22:30:23 -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:288628 Archived-At: No Wayman 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