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 22:30:23 -0400 Message-ID: <87wmlvmh4w.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> <87h6d0xeu5.fsf@gmail.com> <87plrnhoem.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16972"; 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 Tue Jul 09 04:32:14 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 1sR0eM-0004Gt-5l for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Jul 2024 04:32:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sR0e6-0006qv-Ad; Mon, 08 Jul 2024 22:31: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 1sR0e5-0006qm-6O for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 22:31: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 1sR0e4-0001BQ-TH for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 22:31:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sR0eA-0002hK-28 for bug-gnu-emacs@gnu.org; Mon, 08 Jul 2024 22:32: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: Tue, 09 Jul 2024 02:32: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.172049230610348 (code B ref 69410); Tue, 09 Jul 2024 02:32:02 +0000 Original-Received: (at 69410) by debbugs.gnu.org; 9 Jul 2024 02:31:46 +0000 Original-Received: from localhost ([127.0.0.1]:51755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR0du-0002gq-Cy for submit@debbugs.gnu.org; Mon, 08 Jul 2024 22:31:46 -0400 Original-Received: from mail-qv1-f49.google.com ([209.85.219.49]:47159) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR0dt-0002gh-92 for 69410@debbugs.gnu.org; Mon, 08 Jul 2024 22:31:45 -0400 Original-Received: by mail-qv1-f49.google.com with SMTP id 6a1803df08f44-6b5d3113168so26675276d6.2 for <69410@debbugs.gnu.org>; Mon, 08 Jul 2024 19:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720492239; x=1721097039; darn=debbugs.gnu.org; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:from:to:cc:subject:date:message-id:reply-to; bh=Cp5mZn7R9cy6RV/xhfpjgzcw1UVgXlEfvrhSkt/aSYc=; b=cYdUSY921BxnQiz3l3CtEiIET6hJoevsyOU1n77kMiyt2e7K45hUd6Xg/mHTJXLSI3 IURubmC0AEKdZdymrY+y2iMfATlXy2v/+gNlQ8pZo+xOjD69kSn7wRvQaTtfxD+bzeMJ wgtr0MTBPW64azelK4xFpljM1lGal/pKb64bCefJh1LSiRA7ftJxdPkivPrK4I3oGm+4 l2r+jU6jSnr6nTzv6E0vT2AGm8P3vc8HicH8AIvA9bUklqg/LgDVODxmSyTiSohqGVYJ mo7tu0vklhQy1VK1IUBPJA0UjoQKdsbtXr0sSoOZLNGljZsdgqOpWKXtqO+rnSnvmLqV RG2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720492239; x=1721097039; h=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=Cp5mZn7R9cy6RV/xhfpjgzcw1UVgXlEfvrhSkt/aSYc=; b=fNvi/8CImhVPpw/op7rDI9T4OtUrMAKW/olk7H7UbGAMLKfzuIkS1BUDtlMxvGsOzj e48bcvtMYnflB3SnlID3eJTUT78oGkXV5u3bUq0nXtr6J8Dzovngx7AZWYFsIf/9zpKz QLcOG9lLrOrR5mNlRZoSetbS5MdwwCWRyuumE+N3hYVkM0tw4GzM+37dJBeUcux52K9V kNyCL5dKld3Pll6nfjrALPrcGGhXEsLdgU3sTqpjcc0S9x3lvHeOhoR4Ee2LsHGrsciH yGATMAiP1Y9wk8NEI9EUcg9rCv3QvaXqSTX8H4MBASjC9NPJnNI4Se6qDC7sBYP0nTR3 WDng== X-Gm-Message-State: AOJu0Ywv5kE0ixEFnHP0nZjbOtoqFVyrIETY+myU/Mkq43nIet/pg2aI y89YY4QsjZ8cEXDcvOMbrMZdMgOK7A5HAO01lNrwmQSlL6KRTg+UeBCw3A== X-Google-Smtp-Source: AGHT+IGOanPZku7z3JuKJC81IgFc+liOW7zWKuKf9F5nQBWk4fYq7K1F1f8AKyAWUpitn6YmPGpEsg== X-Received: by 2002:a05:6214:d4b:b0:6b5:e2da:8bd3 with SMTP id 6a1803df08f44-6b61bc83c07mr18138376d6.4.1720492239495; Mon, 08 Jul 2024 19:30:39 -0700 (PDT) Original-Received: from laptop ([2601:84:847f:c697:e217:2894:4724:14f4]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b61ba73979sm4866636d6.83.2024.07.08.19.30.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jul 2024 19:30:39 -0700 (PDT) In-Reply-To: <87plrnhoem.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 08 Jul 2024 15:52:17 +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:288610 Archived-At: Philip Kaludercic writes: >> 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. > > Doesn't this go against your suggestion to have a uniform > interface? No. The :ensure keyword is the interface. The semantics can vary depending on the package manager, though most cases won't in practice. For example, I would just teach Elpaca and straight to consider :ensure :vc to mean the same as :ensure t. > As we mentioned previously, :vc t can do this as well, without > the > need to handle special values. :vc *is* the 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. (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? > And we have to keep in mind, that use-package was originally > made for package.el, and it was retrofitted to support other > package > managers later on. When considering this context, I think that > privileging built-in functionality like package-vc is > acceptable. That was a wise decision. Otherwise it would be a leakier abstraction than it needs to be. Built-in functionality loses no privilege by making the interface more consistent and flexible, though. > 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. > 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.