From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: No Wayman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 26 Feb 2024 16:26:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69410@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.170896472031271 (code B ref -1); Mon, 26 Feb 2024 16:26:03 +0000 Received: (at submit) by debbugs.gnu.org; 26 Feb 2024 16:25:20 +0000 Received: from localhost ([127.0.0.1]:47564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1redn5-00088B-DB for submit@debbugs.gnu.org; Mon, 26 Feb 2024 11:25:19 -0500 Received: from lists.gnu.org ([209.51.188.17]:42962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1reddP-0005jt-Nw for submit@debbugs.gnu.org; Mon, 26 Feb 2024 11:15:20 -0500 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 1redTy-0005s2-SG for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 11:05:34 -0500 Received: from mail-qt1-x834.google.com ([2607:f8b0:4864:20::834]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1redTr-0005py-Ny for bug-gnu-emacs@gnu.org; Mon, 26 Feb 2024 11:05:32 -0500 Received: by mail-qt1-x834.google.com with SMTP id d75a77b69052e-42e7ed64b5fso4782151cf.1 for ; Mon, 26 Feb 2024 08:05:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708963525; x=1709568325; darn=gnu.org; h=mime-version:message-id:date:user-agent:subject:to:from:from:to:cc :subject:date:message-id:reply-to; bh=NastfV1JniOOutTPcX5X4f8mQjmYyzwx0M0trn2VMmA=; b=UpGfueSlz6ziUKr3HKXMHxPfdnuvQ3cM8qRWdpYLE8gZBAU4Agow5IN53JKCfGj9Mp 9dDh9rjCrUynEJQUoGGGcgaV0vHJMQt8XtIbp4QdNYLSqOX5jzOR6C+gJwxXOwAwDgBU bOsRpRYSKacLUa9UE870+e76jqP+MOPswuAHCF2P23KDiTR3Wu9w7ckeh7dPLhatBKBA c3gWE690+EoIeILp/0e2jHjMfstoKC8wI0jFI2tVBpbxDpaowIt98BeMRSH7Ot6mzGGP Yh4ZQKrQWV8YaK/4yTRBLHhSIrncmNo5wgT4Mul8gfcl+MQrByKLU1ZuWNRSxxwlM+Yt 4KAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708963525; x=1709568325; h=mime-version:message-id:date:user-agent:subject:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=NastfV1JniOOutTPcX5X4f8mQjmYyzwx0M0trn2VMmA=; b=ZAxfvr1uw8cO8DuAayi/OdNIw3394UFG5S5Xa2QBs0CWfe25U0zNK91xWaWyPCD6ic rlTbgIW9qszIf6/6/4QbnrhTjr7Y4l2BDoXLcP/uOn6QT8BuDVr9K74c4GipwFJdqoU/ Uhx0QGCzeCQxzgcaLStQtQEgeF1ioXi1brtljF1dmgrUxNeaaWAycFeFMl8hH1pxxX+U HWceHXPaFktWqTwSW1PdaVvUzl3GwllKxdqN2DXCGtkBZy4nx5tmDnUtKuFw8ogTSNYK VhXTcFwvH2nCsqyp9phUe+v5l+P2/8E2HpT6U8XP87IEvmdKGhkxJEJtUVGkRC02vhn1 ni1A== X-Gm-Message-State: AOJu0Yyyrka77uOKHeH3LnNrirtS9ojr+iFM3ch5zN7z2XCLY+w2DjNn 4RzYk2OD1f1+iBaJAyiYHHEOZNKDdObLX5uwq3857aysB7igHQfXU1ePhNik X-Google-Smtp-Source: AGHT+IF+VvsLxCHJTmtvel+hi4wwsNaaqMKUD/o6vtdx+xejZolwpmE5kGXo3PP3Vuty4+9Ud9esqA== X-Received: by 2002:a05:622a:594:b0:42e:7e22:52c4 with SMTP id c20-20020a05622a059400b0042e7e2252c4mr4309400qtb.52.1708963524840; Mon, 26 Feb 2024 08:05:24 -0800 (PST) Received: from laptop ([2601:84:847f:c697:e217:2894:4724:14f4]) by smtp.gmail.com with ESMTPSA id e4-20020ac84e44000000b0042e9168a936sm322555qtw.87.2024.02.26.08.05.24 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Feb 2024 08:05:24 -0800 (PST) From: No Wayman User-Agent: mu4e 1.11.27; emacs 30.0.50 Date: Mon, 26 Feb 2024 11:06:09 -0500 Message-ID: <87wmqryzv2.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Received-SPF: pass client-ip=2607:f8b0:4864:20::834; envelope-from=iarchivedmywholelife@gmail.com; helo=mail-qt1-x834.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) I think it would be cleaner to allow use-package's :ensure keyword to accept the arguments the :vc keyword currently does. e.g. ;; Install EXAMPLE package from ELPA archive (use-package example :ensure t) ;; Install EXAMPLE package from source (use-package example :ensure (:url "https://www.forge.com/maintainer/example")) My reasoning is that this has greater potential to work across multiple package managers. Instead of each package manager adding their own use-package keyword (e.g. :vc, :straight, :elpaca), they can all interpret the :ensure keyword's value. It would make things simpler for package maintainers offering example declarations and users switching between package managers. Thoughts? From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Jun 2024 10:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: No Wayman Cc: Tony Zorman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.17197441476372 (code B ref 69410); Sun, 30 Jun 2024 10:43:01 +0000 Received: (at 69410) by debbugs.gnu.org; 30 Jun 2024 10:42:27 +0000 Received: from localhost ([127.0.0.1]:55226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNs0p-0001eh-5S for submit@debbugs.gnu.org; Sun, 30 Jun 2024 06:42:27 -0400 Received: from mout02.posteo.de ([185.67.36.66]:37739) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sNs0n-0001eB-Lx for 69410@debbugs.gnu.org; Sun, 30 Jun 2024 06:42:26 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 0C652240105 for <69410@debbugs.gnu.org>; Sun, 30 Jun 2024 12:42:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719744140; bh=QiIPUWPykJDmfszyM7jJr/cJpzAWr0K5Jeonma94oYI=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=I8cleJ2o+ZC8YCS4D7Ex0NFjzIRQ44/DYW0+s17RVb4krjBYWGYuQN0cBuKRFqjuN 2NSdEQrS2uvU2hgjofKyj6WWmIrXzdFo+/IopDGPzd06GLmAOs7jDDO8BuGA9X5RRA Uvp5mRGUDFiJICyF6WOFn4OERFHbUdhyL7+R9YY9gilfG3ZQ0a5eeDNuggW23FqwnG HvweJmoX8rmnEaqsqWMYDIo/bg0uW0wYWGuY3Y28KmRFzFN5B1xCzgR89IXOulax8d nMMGGpO38fsK4282DUoFSJplHvm7sctu9d672yK7nlOpHkSnndY6HP0IdzAL8/jWIw WxQZaRsnaTgSw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WBm2g36yjz6tsg; Sun, 30 Jun 2024 12:42:19 +0200 (CEST) From: Philip Kaludercic In-Reply-To: <87wmqryzv2.fsf@gmail.com> (No Wayman's message of "Mon, 26 Feb 2024 11:06:09 -0500") References: <87wmqryzv2.fsf@gmail.com> OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Date: Sun, 30 Jun 2024 10:42:18 +0000 Message-ID: <87jzi6lnjp.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) No Wayman writes: > I think it would be cleaner to allow use-package's :ensure keyword to > accept the arguments the :vc keyword currently does. e.g. > > ;; Install EXAMPLE package from ELPA archive > (use-package example :ensure t) > > ;; Install EXAMPLE package from source > (use-package example :ensure (:url > "https://www.forge.com/maintainer/example")) > > My reasoning is that this has greater potential to work across > multiple package managers. > Instead of each package manager adding their own use-package keyword > (e.g. :vc, :straight, :elpaca), they can all interpret the :ensure > keyword's value. It would make things simpler for package maintainers > offering example declarations and users switching between package > managers. I am adding Tony to the CCs, as he implemented the :vc keyword to see if he has anything to comment (generally it is good to add a X-Debbugs-CC header, mentioning specific maintainers or people involved in a feature when submitting a bug). My own take is that setting aside timing issues and the fact that the Emacs 30 branch has been cut, ... - The :vc keyword allows just passing t to download the package as specified in the ELPA archive. I don't see an elegant away to allow this using :ensure. - I am not a fan of encouraging the usage of VC packages, since version control brings in some complications that tarballs avoid (especially when it comes to upgrading). - If I try to evaluate the expression you suggest I get a warning: =E2=9B=94 Error (use-package): Failed to parse package example: use-package: :ensure wants an optional package name (an unquoted symbol name), or ( :pin ) and I am wondering, if there is a potentially ambiguous conflict between your suggestion and the ( :pin ) case, that might trigger an edge case in some configuration. > Thoughts?=20 --=20 Philip Kaludercic on peregrine From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Tony Zorman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jul 2024 13:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philip Kaludercic , No Wayman Cc: 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.171984103815974 (code B ref 69410); Mon, 01 Jul 2024 13:38:01 +0000 Received: (at 69410) by debbugs.gnu.org; 1 Jul 2024 13:37:18 +0000 Received: from localhost ([127.0.0.1]:60574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOHDZ-00049Z-Mu for submit@debbugs.gnu.org; Mon, 01 Jul 2024 09:37:18 -0400 Received: from mout-p-201.mailbox.org ([80.241.56.171]:35448) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOHDW-00047s-3e for 69410@debbugs.gnu.org; Mon, 01 Jul 2024 09:37:16 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4WCRsp6vL7z9sZL; Mon, 1 Jul 2024 15:37:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1719841022; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p1fWFD210Szz1yzp7x6+gVbxEBlW/TT5F2rskExEhac=; b=WaXfhK8/zAMxNkMowL7WLoXfdFgtBDNXlFOlFROknrsdIq2DwEpxzy/Jj9xYZicoo9CM1V 1oCxvtTUzAD3Mihc4ZVRAi9EFnbnScQ7JScSxtc4v73QRpAB3FziG56eyfGQRPYCozJ80s xYS3HSWjkFlMOhn1F0txvhUIky9I9rKqKFex90BIiDLPfz/rasOU+G/1w5Nqw32doQZTBM RfhZtsuZAAilCsK3S0CzlxQsKtvRfHeNpUbk5okTcAGlS5IEXskyc1MuUNq0Le64Cp11pR 8h9QyvjKV2WA1ZgwOjoCbIWka7gHjow+lEmxqgkA8rcp8KJbHso02AJ68RL9Fw== From: Tony Zorman In-Reply-To: <87jzi6lnjp.fsf@posteo.net> References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> Date: Mon, 01 Jul 2024 15:37:01 +0200 Message-ID: <87wmm55j42.fsf@hyperspace> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MBO-RS-ID: 87aad044ff180f4b7d9 X-MBO-RS-META: 7ee4ki4dbciis51dfxkpzabh89iziw3e X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Sun, Jun 30 2024 10:42, Philip Kaludercic wrote: > No Wayman writes: > >> I think it would be cleaner to allow use-package's :ensure keyword to >> accept the arguments the :vc keyword currently does. e.g. >> >> ;; Install EXAMPLE package from ELPA archive >> (use-package example :ensure t) >> >> ;; Install EXAMPLE package from source >> (use-package example :ensure (:url >> "https://www.forge.com/maintainer/example")) >> >> My reasoning is that this has greater potential to work across >> multiple package managers. >> Instead of each package manager adding their own use-package keyword >> (e.g. :vc, :straight, :elpaca), they can all interpret the :ensure >> keyword's value. It would make things simpler for package maintainers >> offering example declarations and users switching between package >> managers. > > I am adding Tony to the CCs, as he implemented the :vc keyword to see if > he has anything to comment (generally it is good to add a X-Debbugs-CC > header, mentioning specific maintainers or people involved in a feature > when submitting a bug). Thanks. To be honest, I'm not a big fan of trying to cram everything into :ensure. Implementation wise, I feel like it would make things much messier than they are now=E2=80=94especially if the final goal is to maybe extend this to other package managers. By the same thought, one might argue that something like :load-path should be inlined into :ensure as well, which is not a good idea in my opinion. In either case, I think that (use-package example :ensure (:url "https://www.forge.com/maintainer/example")) is not that much more verbose (or harder to adjust) than (use-package example :ensure t :vc (:url "https://www.forge.com/maintainer/example")) This is especially true since use-package-always-ensure exists (and many people use it) so one would just have to write (use-package example :vc (:url "https://www.forge.com/maintainer/example")) Any kind of backwards compatibility with a hypothetical :straight keyword would not work in either case, because :straight already exists in straight.el and it has a completely different package specification attached to it. > My own take is that setting aside timing issues and the fact that the > Emacs 30 branch has been cut, ... > > - The :vc keyword allows just passing t to download the package as > specified in the ELPA archive. I don't see an elegant away to allow > this using :ensure. Yes backwards compatibility might be a bit of a pain=E2=80=94especially wit= h a view on use-package-always-ensure=E2=80=94save having self-defeating constr= ucts like :ensure (:vc =E2=80=A6). Tony --=20 Tony Zorman | https://tony-zorman.com From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword In-Reply-To: <87wmqryzv2.fsf@gmail.com> Resent-From: No Wayman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jul 2024 14:31:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.171984421222688 (code B ref 69410); Mon, 01 Jul 2024 14:31:02 +0000 Received: (at 69410) by debbugs.gnu.org; 1 Jul 2024 14:30:12 +0000 Received: from localhost ([127.0.0.1]:33467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOI2l-0005tq-Go for submit@debbugs.gnu.org; Mon, 01 Jul 2024 10:30:12 -0400 Received: from mail-qv1-f42.google.com ([209.85.219.42]:47547) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sOI2j-0005sR-8v for 69410@debbugs.gnu.org; Mon, 01 Jul 2024 10:30:10 -0400 Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6b51ae173ceso15372826d6.3 for <69410@debbugs.gnu.org>; Mon, 01 Jul 2024 07:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719844143; x=1720448943; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:references :subject:to:from:from:to:cc:subject:date:message-id:reply-to; bh=2xtzXN8qesyJt4xQUv3itTt9NmBParIfW87/PLF20nc=; b=GRleXECzaGsxHSQXHvlkf2VVWDWesSzpnR6NOSNXbMpbquOANI+x+/WDOa5+IyZ/HD KfZdHG2/DSnHhZeAKM0csjpMvXQg4aoATciGOS7jhOjb3l9bz9o92TV0SUAw22uV3tQr EXJF5kCLdo+TOf/JVfNx8m4lJPA0V2cUoiPxbp2ev1pViBmvXTzacEkZzW3eU2fSp5Wv mK5WlUnzJ4rA8ODgxGjMb8sPWkIU9j/qjcRlZAEh4lOferw8QFkgLp/kG4vZS1s7zFLW Q7nPI3o3vUMSVSdPmxMpR+/feas0HHCzz36SdKKeqARMJClcNykXec5J7HFpubFLTaME Aa2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719844143; x=1720448943; h=content-transfer-encoding:mime-version:message-id:date:references :subject:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2xtzXN8qesyJt4xQUv3itTt9NmBParIfW87/PLF20nc=; b=H+u4DhUnhmSvER36OakXgh8jMXgwro5EjK9beFA6Bt0T8nh/ThimcLQks8+CERcf8A uh1oIceeSSiy6tgyAXzRDCnvgHfHtT3la4mZdP9C0F/z74yGsC/BNjA3xjwgcohLYL7I 3RNUkXg9E0o1DQSTASLzUhGsa3DlkpFeJINBhWS1i2toktx6Sg8qed3H3lY7fQ2grHf5 5PZuvZhN3dLniwB4UNs0eikqbPbhu2tcHzUDaULb7ldFQh/FfNUeplvKDGfz75JgPEdq 5J0Pcumx4e7InpA/XStTCYf2vNR7fnK0txVLXwsVOQOwhtiCdjKpqpxGjUWaA6X/KnIX HIvQ== X-Gm-Message-State: AOJu0Yz/pLkDXTcVPlE045SxrfoxKsgMsw1fDkPJqFj1oRFqiwJzBt/W C9zYPNgY7tefIO0Gkjo29Me7D14vhttPeYdIBBjip1n+i0g9PKenQ2mdhA== X-Google-Smtp-Source: AGHT+IFQKRuBWGiXYl/a0M2JSH7bhEmLxFNYCusE0W+ktlv1mdtsnUZ/dG38KBvs9pzublNiU36/vA== X-Received: by 2002:ad4:5e87:0:b0:6b5:905a:f528 with SMTP id 6a1803df08f44-6b5b71a5d3fmr66204986d6.41.1719844142780; Mon, 01 Jul 2024 07:29:02 -0700 (PDT) Received: from laptop ([2601:84:847f:c697:2d4:9eff:feb6:970c]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b59e368b4dsm33527296d6.28.2024.07.01.07.29.02 for <69410@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Jul 2024 07:29:02 -0700 (PDT) From: No Wayman References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <87zfr15hqj.fsf@gmail.com> Date: Mon, 01 Jul 2024 10:28:50 -0400 Message-ID: <87v81p5gpp.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) -------------------- Start of forwarded message=20 -------------------- From: No Wayman To: Tony Zorman Subject: Re: bug#69410: 30.0.50; [WISHLIST] Use-package: allow=20 :ensure to accept package spec instead of separate :vc keyword Date: Mon, 01 Jul 2024 10:06:44 -0400 Tony Zorman writes: > Thanks. To be honest, I'm not a big fan of trying to cram=20 > 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 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. > By the same thought, one might > argue that something like :load-path should be inlined into=20 > :ensure as > well, which is not a good idea in my opinion. No one is arguing that. =20 > In either case, I think that > > (use-package example > :ensure (:url "https://www.forge.com/maintainer/example")) > > is not that much more verbose (or harder to adjust) than > > (use-package example > :ensure t > :vc (:url "https://www.forge.com/maintainer/example")) This is not what package authors provide in practice. 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. =20 > This is especially true since use-package-always-ensure exists=20 > (and many > people use it) so one would just have to write It's not about the `:ensure t`, it's about every package manager=20 requiring their own, separate interface to use-package, when they=20 basically operate on the same data structure. > Any kind of backwards compatibility with a hypothetical=20 > :straight > keyword would not work in either case, because :straight already=20 > exists > in straight.el and it has a completely different package=20 > specification > attached to it. Not asking for this, either. I'd like to see the `:straight` keyword go away. Making that happen would be the burden of straight's maintainers=20 (of which I am one). =20 >> My own take is that setting aside timing issues and the fact=20 >> that the >> Emacs 30 branch has been cut, ... I brought it up well before then, but nobody was interested/aware=20 enough to reply. (Not the first time it's happened on these mailing lists, and a=20 primary reason I seldom chime in.)=20 >> - The :vc keyword allows just passing t to download the package=20 >> as >> specified in the ELPA archive. I don't see an elegant away=20 >> to allow >> this using :ensure. > > Yes backwards compatibility might be a bit of a pain=E2=80=94especially=20 > with a > view on use-package-always-ensure=E2=80=94save having self-defeating=20 > constructs > like :ensure (:vc =E2=80=A6). It's evident there's little enthusiasm for the idea now, too. That being the case, I'll relax the constraints on Elpaca's recipe=20 format I placed in hopes of offering an easier switch between=20 package managers for users. Thanks for the input. -------------------- End of forwarded message -------------------- From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 01 Jul 2024 19:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Tony Zorman Cc: No Wayman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.17198638744010 (code B ref 69410); Mon, 01 Jul 2024 19:58:01 +0000 Received: (at 69410) by debbugs.gnu.org; 1 Jul 2024 19:57:54 +0000 Received: from localhost ([127.0.0.1]:34740 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sON9u-00012c-AT for submit@debbugs.gnu.org; Mon, 01 Jul 2024 15:57:54 -0400 Received: from mout01.posteo.de ([185.67.36.65]:53105) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sON9r-00012N-RE for 69410@debbugs.gnu.org; Mon, 01 Jul 2024 15:57:53 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 995B8240027 for <69410@debbugs.gnu.org>; Mon, 1 Jul 2024 21:57:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1719863864; bh=/Xpwk4A7zgd8fz9aJYF/cK+50vFBbacqOd9SMReyQSw=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=D0sFCqHmzW5tcRvFB7GqXiSJ+kKiNeCbbfcV+Gpz8sQxZhq9njTaKEprB8252e4N0 /JErMkx9oGfkvXXazUgTExAKa0iOTNtsgeUeYRbeXbubGZLB4CXWUO1/DVYaWFJw6e HvR7cQawMdDLDoI6Mg1bISFApGAL92Io421++Rw+bMeDCBVHBNrDd3wSwnfRjmCLM8 DOyXxnxXX9iz3B+ojNGjasa9SP1soyPQt6+50sEkDSBTYp/7OHa3nosaC7om6NEott Ngq8J2/52jgGFimFWrizYc11g0tAWemBFY+ViOq6w1uroiRoSkw31SnCTPifhgZmS+ R5EE1comfPsog== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WCcK34MCvz9rxB; Mon, 1 Jul 2024 21:57:42 +0200 (CEST) From: Philip Kaludercic In-Reply-To: <87wmm55j42.fsf@hyperspace> (Tony Zorman's message of "Mon, 01 Jul 2024 15:37:01 +0200") References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Date: Mon, 01 Jul 2024 19:57:42 +0000 Message-ID: <878qyk7umh.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Tony Zorman writes: > On Sun, Jun 30 2024 10:42, Philip Kaludercic wrote: >> No Wayman writes: >> >>> I think it would be cleaner to allow use-package's :ensure keyword to >>> accept the arguments the :vc keyword currently does. e.g. >>> >>> ;; Install EXAMPLE package from ELPA archive >>> (use-package example :ensure t) >>> >>> ;; Install EXAMPLE package from source >>> (use-package example :ensure (:url >>> "https://www.forge.com/maintainer/example")) >>> >>> My reasoning is that this has greater potential to work across >>> multiple package managers. >>> Instead of each package manager adding their own use-package keyword >>> (e.g. :vc, :straight, :elpaca), they can all interpret the :ensure >>> keyword's value. It would make things simpler for package maintainers >>> offering example declarations and users switching between package >>> managers. >> >> I am adding Tony to the CCs, as he implemented the :vc keyword to see if >> he has anything to comment (generally it is good to add a X-Debbugs-CC >> header, mentioning specific maintainers or people involved in a feature >> when submitting a bug). > > Thanks. To be honest, I'm not a big fan of trying to cram everything > into :ensure. Implementation wise, I feel like it would make things much > messier than they are now=E2=80=94especially if the final goal is to maybe > extend this to other package managers. By the same thought, one might > argue that something like :load-path should be inlined into :ensure as > well, which is not a good idea in my opinion. > > In either case, I think that > > (use-package example > :ensure (:url "https://www.forge.com/maintainer/example")) > > is not that much more verbose (or harder to adjust) than > > (use-package example > :ensure t > :vc (:url "https://www.forge.com/maintainer/example")) BTW Does it ever make sense to give a :vc keyword without :ensure t or enabling `use-package-always-ensure'? > This is especially true since use-package-always-ensure exists (and many > people use it) so one would just have to write > > (use-package example > :vc (:url "https://www.forge.com/maintainer/example")) > > Any kind of backwards compatibility with a hypothetical :straight > keyword would not work in either case, because :straight already exists > in straight.el and it has a completely different package specification > attached to it. 1+ >> My own take is that setting aside timing issues and the fact that the >> Emacs 30 branch has been cut, ... >> >> - The :vc keyword allows just passing t to download the package as >> specified in the ELPA archive. I don't see an elegant away to allow >> this using :ensure. > > Yes backwards compatibility might be a bit of a pain=E2=80=94especially w= ith a > view on use-package-always-ensure=E2=80=94save having self-defeating cons= tructs > like :ensure (:vc =E2=80=A6). I am not sure what you mean here? > Tony --=20 Philip Kaludercic on peregrine From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Tony Zorman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Jul 2024 19:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: No Wayman Cc: Philip Kaludercic , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.172003633812692 (code B ref 69410); Wed, 03 Jul 2024 19:53:01 +0000 Received: (at 69410) by debbugs.gnu.org; 3 Jul 2024 19:52:18 +0000 Received: from localhost ([127.0.0.1]:40632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP61a-0003Ie-9Q for submit@debbugs.gnu.org; Wed, 03 Jul 2024 15:52:18 -0400 Received: from mout-p-102.mailbox.org ([80.241.56.152]:56424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP61X-0003IG-Cb for 69410@debbugs.gnu.org; Wed, 03 Jul 2024 15:52:16 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4WDr512pQQz9spv; Wed, 3 Jul 2024 21:51:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1720036293; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0KQcnFevHKOkilRM/gm+pTJdoHONELq5fxkBTLEWBwg=; b=rG4NHrlEphIMWVYhOdyWXpkrrlMXLmLmXAU4Pad3YsumM77cG/a4dDYvugUBbZa2pFp/pH ugtjkeoVUM9FC2GQpf4F4raHSdWdsBJk0byCTgS+DCX0G93FtKJUpoDfznNgyo8uerP4A2 dEvTAv9nlhl8Mshf2NTNbPgGOGQiqMMGmWNBzfpmTtF0hoOH7bwMxl9QgvXOvdFmr8MrMF YP9AOMoxlBImN8jvddoUdI7BNrZlKwa6Umo8bQfC0veTdmIyxj7DjFzDPyicY/gJ7SCzrq /W1qzKt7SDeYYRBqIEZm9s9ZMEhJ75/MwkLWpVAixYz+hAU9A56jknr/OSTNew== From: Tony Zorman In-Reply-To: <87zfr15hqj.fsf@gmail.com> References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <87zfr15hqj.fsf@gmail.com> Date: Wed, 03 Jul 2024 21:51:29 +0200 Message-ID: <8734oqmeym.fsf@hyperspace> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MBO-RS-META: bjp53znntkdphg3j6ew8ih1jspq7oswp X-MBO-RS-ID: 4c177f79f6da8b3cc5e X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 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 > > 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. > 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=94right now=E2=80=94support this schema are package.el (by means of :vc) and elpaca, right? Tony --=20 Tony Zorman | https://tony-zorman.com From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Tony Zorman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 03 Jul 2024 19:58:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philip Kaludercic Cc: No Wayman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.172003663513362 (code B ref 69410); Wed, 03 Jul 2024 19:58:01 +0000 Received: (at 69410) by debbugs.gnu.org; 3 Jul 2024 19:57:15 +0000 Received: from localhost ([127.0.0.1]:40701 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP66M-0003TS-PD for submit@debbugs.gnu.org; Wed, 03 Jul 2024 15:57:15 -0400 Received: from mout-p-201.mailbox.org ([80.241.56.171]:42424) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sP66K-0003T5-J5 for 69410@debbugs.gnu.org; Wed, 03 Jul 2024 15:57:13 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4WDrBm5j82z9scN; Wed, 3 Jul 2024 21:56:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailbox.org; s=mail20150812; t=1720036592; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N3pdi4MJoJ+g1MDXOFRUOpSEcW502FcnByNuvgwHc8c=; b=I10K76l9UrJKEjNY5N4LQKdKF9/ttcQVu8oyFvgZ7+B525bRlaC6lNJR/V8oAXSuZnGZJe Fj19gNd+E0omJC9d/rFfTI2s/pkkBDjMFHhgC9LXbsi9W11jNI7ffyhnkZFHVPsCjneag4 d92Gxck7Ag5P5q8HDvidY18TYUh1KICyb0YJ4c2k3lk8PeXMSq33izs+Ga8qLmeZR4Uu2d 1GeRbgpYFmz67HBl3rqiOtFA5vTYpcA8YMGi2bwo9k+usWUdSUw/QPCfW8+SoIuiJi+aLa AtR+yojKw5Ve2BAuHbZceWzR8aQnHzJp3/K4vEL/vW2BYXk7lzdrmmePDBk8NQ== From: Tony Zorman In-Reply-To: <878qyk7umh.fsf@posteo.net> References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <878qyk7umh.fsf@posteo.net> Date: Wed, 03 Jul 2024 21:56:31 +0200 Message-ID: <87zfqyl05s.fsf@hyperspace> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-MBO-RS-ID: 8a191ad1e6c739604da X-MBO-RS-META: tx4689h98zia79i6h6jjisbe6qirrsxb X-Spam-Score: -0.7 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On Mon, Jul 01 2024 19:57, Philip Kaludercic wrote: > Tony Zorman writes: > > [=E2=80=A6 41 lines elided =E2=80=A6] > >> (use-package example >> :ensure t >> :vc (:url "https://www.forge.com/maintainer/example")) > > BTW Does it ever make sense to give a :vc keyword without :ensure t or > enabling `use-package-always-ensure'? Ah, this is a good point (which I had completely forgotten!). Since package-vc.el is the only backend that :vc needs to support right now, we actually completely circumvent :ensure (which by default just calls out to the package archives). When :vc is present then whatever argument is given to :ensure is disregarded. Tony --=20 Tony Zorman | https://tony-zorman.com From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword 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 X-GNU-PR-Keywords: To: No Wayman Cc: Tony Zorman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.172003891217491 (code B ref 69410); Wed, 03 Jul 2024 20:36:01 +0000 Received: (at 69410) by debbugs.gnu.org; 3 Jul 2024 20:35:12 +0000 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 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 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== 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) From: Philip Kaludercic In-Reply-To: <87v81p5gpp.fsf@gmail.com> (No Wayman's message of "Mon, 01 Jul 2024 10:28:50 -0400") References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <87zfr15hqj.fsf@gmail.com> <87v81p5gpp.fsf@gmail.com> OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Date: Wed, 03 Jul 2024 20:34:52 +0000 Message-ID: <87wmm21afn.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword 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 X-GNU-PR-Keywords: To: Philip Kaludercic Cc: Tony Zorman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.17204408216994 (code B ref 69410); Mon, 08 Jul 2024 12:14:02 +0000 Received: (at 69410) by debbugs.gnu.org; 8 Jul 2024 12:13:41 +0000 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 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 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) 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) From: No Wayman In-Reply-To: <87wmm21afn.fsf@posteo.net> (Philip Kaludercic's message of "Wed, 03 Jul 2024 20:34:52 +0000") References: <87wmqryzv2.fsf@gmail.com> <87jzi6lnjp.fsf@posteo.net> <87wmm55j42.fsf@hyperspace> <87zfr15hqj.fsf@gmail.com> <87v81p5gpp.fsf@gmail.com> <87wmm21afn.fsf@posteo.net> Date: Mon, 08 Jul 2024 08:12:18 -0400 Message-ID: <87h6d0xeu5.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Jul 2024 15:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: No Wayman Cc: Tony Zorman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.1720453956692 (code B ref 69410); Mon, 08 Jul 2024 15:53:01 +0000 Received: (at 69410) by debbugs.gnu.org; 8 Jul 2024 15:52:36 +0000 Received: from localhost ([127.0.0.1]:51306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQqfL-0000B5-K3 for submit@debbugs.gnu.org; Mon, 08 Jul 2024 11:52:36 -0400 Received: from mout01.posteo.de ([185.67.36.65]:51257) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sQqfH-0000Ao-Ld for 69410@debbugs.gnu.org; Mon, 08 Jul 2024 11:52:33 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id AC534240027 for <69410@debbugs.gnu.org>; Mon, 8 Jul 2024 17:52:19 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720453939; bh=z8gEV1J4WP/slzCYy3t2dDY0XAbnDd+Od4HiLA9vS70=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:Content-Transfer-Encoding:From; b=SIV02vjViaYBvwPAT1+0Lycwl3i0qSPNTdSDMbqv9XK3XeqGCyUVfwKdPcHODClSm YZTfDFUGigZzLIqh2EqPX6sXY5KJD/7iYo+3anMODa3TCRHFvDraZPzsgGlYEkjxbn F9rQKFHMgetMwqUp/JZtGi5AIREIxFmU7rvlA/qN/6XPsFoMx1nBMRDj6MK4EiaV/R PvE3opu7rLD99c6K4SgNeBZL4Tj4WoDohKHGAJNJ/zmEn5tZ84ARqEVT+WX5G+DetY d3QafYpB6QCFK4QZxSVjquSjQixSFuk8griKiI/WLbHzUjYhGFy3WmuLJa6W75tzJZ SpaL1MIVpUj6A== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WHpXf3FNJz6tvm; Mon, 8 Jul 2024 17:52:18 +0200 (CEST) From: Philip Kaludercic In-Reply-To: <87h6d0xeu5.fsf@gmail.com> (No Wayman's message of "Mon, 08 Jul 2024 08:12:18 -0400") 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> OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Date: Mon, 08 Jul 2024 15:52:17 +0000 Message-ID: <87plrnhoem.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) No Wayman writes: > Philip Kaludercic 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 >> >> 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. We can't change that here; I just want you to know what you can do within the existing structures to improve communication. > Odd to me that whatever you're viewing the list with would exclude > feature requests by default, too. I use the "debbugs" package, and was surprised as well. >>>> :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.=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. > > 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? As we mentioned previously, :vc t can do this as well, without the need to handle special values. >> 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. 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. >>>> 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 =E2=80=98:ensure=E2=80=99. > > 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. Hmm, I get this point, but I don't see a neat and safe way to extend :ensure. 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. >>> Just to make sure: in practice, the only package managers >>> that=E2=80=94right >>> now=E2=80=94support 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). FWIW package-vc uses the same package specification format as elpa-admin, with the explicit intention of making it easier to contribute these specifications to elpa.git/nongnu.git. > 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. Again, here we just re-use what ELPA-admin provides. Both keywords are used by ELPA packages, so we need to support them as well. Overall I am not that convinced that there is a worthwhile advantage in trying to unify these keywords. 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. --=20 Philip Kaludercic on peregrine From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword 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 X-GNU-PR-Keywords: To: Philip Kaludercic Cc: Tony Zorman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.172049230610348 (code B ref 69410); Tue, 09 Jul 2024 02:32:02 +0000 Received: (at 69410) by debbugs.gnu.org; 9 Jul 2024 02:31:46 +0000 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 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 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) 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) From: No Wayman In-Reply-To: <87plrnhoem.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 08 Jul 2024 15:52:17 +0000") 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> Date: Mon, 08 Jul 2024 22:30:23 -0400 Message-ID: <87wmlvmh4w.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2024 07:35:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philip Kaludercic Cc: Tony Zorman , No Wayman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.17205104727665 (code B ref 69410); Tue, 09 Jul 2024 07:35:01 +0000 Received: (at 69410) by debbugs.gnu.org; 9 Jul 2024 07:34:32 +0000 Received: from localhost ([127.0.0.1]:52038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR5Mt-0001zZ-Lq for submit@debbugs.gnu.org; Tue, 09 Jul 2024 03:34:32 -0400 Received: from mout.gmx.net ([212.227.17.22]:60047) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR5Mr-0001zM-Jq for 69410@debbugs.gnu.org; Tue, 09 Jul 2024 03:34:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1720510454; x=1721115254; i=michael.albinus@gmx.de; bh=RttySrBylsu4iaghRxAihFaG/mvxXDVyjg50wBel7XM=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=joy7P152GIPGI9hVXb7q7N4xRmTFiQW6pW8vEhQ8JTe/cAtIYE+c/qOM6CNNpexM FjyYknbSLNA9s71oRSU1ArLLH2kzmWz+oSRqLC2Id8xnUmD/N3jI7tk5Ufgp4FLLI 7TBgwxiD+fUYn2XiY3PjG/AYnPX8RTBnaFx97Tx+RONJWY55pKv4gFpepzSYIpGMF UGLJtdcfE+zlARNn/Xwj1p9bN4BK2Fw9ZmuA4PUTJEdJJpzzcJOlNW9tomzlx9SLs HBxNJkT0FCi+TJEP/yu6ACAMyF0Kxh+rXz3AP84DT0XVAYZRMmqepBcliGIggVOoR Jp1adrCIJ2UC+P2V5g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from gandalf.gmx.de ([185.89.38.155]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M3lYB-1sRuJJ1A7n-00GvBy; Tue, 09 Jul 2024 09:34:14 +0200 From: Michael Albinus In-Reply-To: <87plrnhoem.fsf@posteo.net> (Philip Kaludercic's message of "Mon, 08 Jul 2024 15:52:17 +0000") 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> Date: Tue, 09 Jul 2024 09:34:11 +0200 Message-ID: <875xtfxbm4.fsf@gmx.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:5IdmcKEnIRBghKtDwb8qv2V/PDNX1IgrUs8xqB33CuxsjppKkwM hts9vDReYodyr2K/S3D3WLhdjXN3mjslnInPYYCynZtL6xRaDHuLd0ZhxXj25moSMOrbZs8 K85FUEuKj37J9BeanonYYPMs7U3uzAaJPpCb7y4LB4NwuDQHXQTVR/5I6ttmptmLVKSoCFj TW5pa30HMEZZhUl/iy+cg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:920Q/j/0KY4=;L16zn8h/bChr/mB0UA4iGnXZoAd ZmmlWPgzF2BXj8Ajbp6TY1+3GpGFCfEfZ82FqcE9So85yse8SWbYokuuB2WbyNXjYftsdvZK9 5fxZaKhvThdSfdWORFMjuG00JSHheTn538DkNm6LT4SXg5ujhUw2kCslEfc6FYMrKzE5hXUdW Lj2O0KcF+r2Jwif7o3vU+RYEMS/COiU18jKio8xx8IkfaztWP579m6BQiZZrOqgyqWxWEAcYY T/CSigPToQKYUzsY5ksmn7oUTou1E/wsvi3H4FMpdLI/Z97V9gcBwL642tyKWm+jlsRMNQLEK UGShU0wCqjoVyly053YFQ53l2Tn7N4G6Wn1CCPimxRgfDIAnpoWfxCOTE8/QCwuU6/ZAhPbsn 1jdSVaVLsLPnWNVTS3psM149s7ET9nclnleZM6W48PI0YoRq6qHUPFv3WBaUBWLKI6sUWelnp LOibLKZbsLdjTr3yfX3Y8VnBz6jq6Xxu99BJjXFaajLGEJb0keZCkOFSq2VTykTM87Rr9j3sG cLtOdkmE2sziXDbWd3E2HPXVM2puAABVwig2U85TrG8M+PqLbKof0g9LZJ8TIHqko8AidSFwB 7Mkzi2HStWHu+6pL3laDLdtN9WAR70NjFke8lsqRYcUolf/ZWv+LANAitNpxp1E5CDBlhquYK WuBZ5Hvnlp9g3LOkMCiluBvmljtWMuUuTvmK8MKO/AbFiKsiMiwhTTv9AOYIlrhZdGiD3Nu7Z GX45ZRJBLUnJkGSp98sxx1R0kANODmlhHSuxEskAfIh7J+je/+mPtC/48bbzOjVC383W3k7og 4csgHHDkq8hFsTJKzAVXSNIddJT/VQENeqZscQ9GfEK8o= X-Spam-Score: 2.9 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Philip Kaludercic writes: > No Wayman writes: >> Odd to me that whatever you're viewing the list with would exclude >> feature requests by default, too. Content analysis details: (2.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [185.89.38.155 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.9 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Philip Kaludercic writes: > No Wayman writes: >> Odd to me that whatever you're viewing the list with would exclude >> feature requests by default, too. Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [212.227.17.22 listed in list.dnswl.org] 3.6 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS [185.89.38.155 listed in zen.spamhaus.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (michael.albinus[at]gmx.de) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager Philip Kaludercic writes: > No Wayman writes: >> Odd to me that whatever you're viewing the list with would exclude >> feature requests by default, too. Really? On the debbugs.gnu.org web page, wishlist bugs are listed. > I use the "debbugs" package, and was surprised as well. Really? It is up to you to configure your preferences. I have heard of people who did profit from reading the respective info manual. Best regards, Michael. From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2024 08:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Michael Albinus Cc: Tony Zorman , No Wayman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.172051362412749 (code B ref 69410); Tue, 09 Jul 2024 08:28:01 +0000 Received: (at 69410) by debbugs.gnu.org; 9 Jul 2024 08:27:04 +0000 Received: from localhost ([127.0.0.1]:52092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR6Bk-0003JZ-B6 for submit@debbugs.gnu.org; Tue, 09 Jul 2024 04:27:04 -0400 Received: from mout01.posteo.de ([185.67.36.65]:47165) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR6Bh-0003J1-4j for 69410@debbugs.gnu.org; Tue, 09 Jul 2024 04:27:02 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 15879240028 for <69410@debbugs.gnu.org>; Tue, 9 Jul 2024 10:26:47 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1720513609; bh=A6RvedTFoaC/b2qFcBYfTGD70OBcw2ADE+lzrmIpx5U=; h=From:To:Cc:Subject:OpenPGP:Date:Message-ID:MIME-Version: Content-Type:From; b=HRT6Kynw69a1fw6eMnz1+zvScrvivHr0W7PGKsv6u901d2+NJtL94Dn6SQzBPE7xg yg6xbFCoMPn0EAClw+ABEYYZuwdEM+m3iTsqItqOXL+bO+SMs1Zx6iWmlUwTABMT/T q+E0XOF7D0GRKODVcRTZh3eud270uza0KJl/3kmAhhpYeplmb3p0qmktt+sfYqnaS8 QH39v+TJvvH2IA44Pc60hV2O28j/mls9XmN8lh9lB/jvQwnGxWH2zv6UTLoBZC1+DG pqB/4Xni6+dNsb9GdMbyVidy1RrSDcw/hA7oDEbT5hfslozPVZTL3sQlMEcN4dJ0yd l6BiVfJ5qcVMA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WJDc66ytcz9rxD; Tue, 9 Jul 2024 10:26:46 +0200 (CEST) From: Philip Kaludercic In-Reply-To: <875xtfxbm4.fsf@gmx.de> (Michael Albinus's message of "Tue, 09 Jul 2024 09:34:11 +0200") 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> <875xtfxbm4.fsf@gmx.de> OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Date: Tue, 09 Jul 2024 08:26:46 +0000 Message-ID: <87msmrhsxl.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Michael Albinus writes: > Philip Kaludercic writes: > >> No Wayman writes: > >>> Odd to me that whatever you're viewing the list with would exclude >>> feature requests by default, too. > > Really? On the debbugs.gnu.org web page, wishlist bugs are listed. > >> I use the "debbugs" package, and was surprised as well. > > Really? It is up to you to configure your preferences. I have heard of > people who did profit from reading the respective info manual. That is true, the `debbugs-gnu-default-severities' user option just doesn't list wishlist by default, and I always use the default severities, and never noticed that I was missing out on something. > Best regards, Michael. -- Philip Kaludercic on peregrine From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword 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 X-GNU-PR-Keywords: To: No Wayman Cc: Tony Zorman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.172051576327161 (code B ref 69410); Tue, 09 Jul 2024 09:03:02 +0000 Received: (at 69410) by debbugs.gnu.org; 9 Jul 2024 09:02:43 +0000 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 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 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== 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) From: Philip Kaludercic In-Reply-To: <87wmlvmh4w.fsf@gmail.com> (No Wayman's message of "Mon, 08 Jul 2024 22:30:23 -0400") 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> OpenPGP: id=7126E1DE2F0CE35C770BED01F2C3CC513DB89F66; url="https://keys.openpgp.org/vks/v1/by-fingerprint/7126E1DE2F0CE35C770BED01F2C3CC513DB89F66"; preference=signencrypt Date: Tue, 09 Jul 2024 09:02:03 +0000 Message-ID: <87frsjhras.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: 30.0.50; [WISHLIST] Use-package: allow :ensure to accept package spec instead of separate :vc keyword Resent-From: No Wayman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2024 09:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philip Kaludercic Cc: Tony Zorman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.172051909232132 (code B ref 69410); Tue, 09 Jul 2024 09:59:02 +0000 Received: (at 69410) by debbugs.gnu.org; 9 Jul 2024 09:58:12 +0000 Received: from localhost ([127.0.0.1]:52169 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR7bw-0008MB-9b for submit@debbugs.gnu.org; Tue, 09 Jul 2024 05:58:12 -0400 Received: from mail-yb1-f179.google.com ([209.85.219.179]:44172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sR7bu-0008Lx-5R for 69410@debbugs.gnu.org; Tue, 09 Jul 2024 05:58:11 -0400 Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-dff1ccdc17bso5366757276.0 for <69410@debbugs.gnu.org>; Tue, 09 Jul 2024 02:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720519019; x=1721123819; 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=n+acXOwFEHYwxeWY+KaHYQ+O58fcfmZjoQGOyHDRP7I=; b=f4W9cyK3zE7jA9ExT6vy89gH7TCzfPtiNbZOUEBG2d1oQ/3mXfTntrGSKPr2fBkxQC gwB6jarnN31DlmcDSbymO648wxC+7oAtOKkGU85cpzg+q1dqxVe5LIcq9TGGDeu3DRdq 66xa8FHYIZT/1+ohyEIylWgSLqDPY4lKkSzPeQ2tEqRWe1ww4mMvUvK/xECi5H2FB/6b n4BkMXJNUlzKldx7uXO7NAN3TJnkMt/gDerRatgq5ZOlDP++SLDoWFo0ENGxZymFLPBi tsbHbHiYAtytLkkniizpbEgcZxudWQiLDrBbla9Cq+GnPfkzbpGwu135VoaVTIaA7Nnf Q/vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720519019; x=1721123819; 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=n+acXOwFEHYwxeWY+KaHYQ+O58fcfmZjoQGOyHDRP7I=; b=qZ3R4njjLINxx8r5dC2mdZaRDvmS84uJywX12mxiIgabHjVc0yl8OJMdeD+LV8hg0g nwHr59Fj6FznJ7k8FZFI+5RhRavO+qwMw+zMGGD78/S+LEdb8i3Bg1ekvxI84O9yHQFT rcTo6x7ZP2tdkDt2aDcsazvrHgIm5wKi/cszTziKkn4vR5y6KgKIq4WJLSXRScGXgGjS d+UZRsR9O86eiaVA4QxEBgM7uivNxpgkZbF3wAg6Aeucsz6q/34AWvUuCqchDZ+sjurj 20Rj5sd6uiYe2aPXmLZDIB33EpTcl0GZFoz14RlenurxIPJByvLzzge62l4Z8RgbyNi0 o4yw== X-Gm-Message-State: AOJu0YwK/lvCibwT/tX23a7zhgCriwoAgUrS4b65jby+aRkGIrVuoy3M JmZv0nVvhC28jBLO6p6VpCrVuosY23x9mSuRt2Li25c3zTsGiN6I X-Google-Smtp-Source: AGHT+IFaSOunVbYH1HDUM9+J+luGDWVwFdFOgF88TJZW4PcXy3THNccFiUPlNVaXR0LxYBypu3Jkzw== X-Received: by 2002:a25:f206:0:b0:e03:b319:e026 with SMTP id 3f1490d57ef6-e041b17856emr2294203276.52.1720519018960; Tue, 09 Jul 2024 02:56:58 -0700 (PDT) Received: from laptop ([2601:84:847f:c697:e217:2894:4724:14f4]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6b61b9f71e9sm7251776d6.53.2024.07.09.02.56.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Jul 2024 02:56:58 -0700 (PDT) From: No Wayman In-Reply-To: <87frsjhras.fsf@posteo.net> (Philip Kaludercic's message of "Tue, 09 Jul 2024 09:02:03 +0000") 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> <87frsjhras.fsf@posteo.net> Date: Tue, 09 Jul 2024 05:56:42 -0400 Message-ID: <87zfqqhorp.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Philip Kaludercic writes: >> :vc *is* the special value. > > Yes? My point is that I think it would be better to avoid a > special > value? I meant it is a special value at the top-level of a use-package statement, too. Even "more special" in that case. >> 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. I understand your preference for package.el + tarballs, but not everyone shares that preference. > 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? Drop :vc; extend :ensure. There is no package named ":vc" and, in practice, there are no packages (out of the roughly 7 thousand I've seen) that make use of a keyword as their prefix. >>> 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'll let someone else spend the effort there (and on the ensuing discussion). > 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). As long as there are many top-level use-package keywords which do essentially the same thing as :ensure, package authors will want to do this to cater to as many users as possible. The "value" of the keyword is the same most of the time (a simple `t` or the feature name). The current situation demands that the *keyword* is always different. We're talking in circles now, though. From unknown Sun Jun 22 04:30:16 2025 X-Loop: help-debbugs@gnu.org Subject: bug#69410: closing this bug References: <87wmqryzv2.fsf@gmail.com> In-Reply-To: <87wmqryzv2.fsf@gmail.com> Resent-From: Sean Whitton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Mar 2025 07:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69410 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philip Kaludercic Cc: Tony Zorman , No Wayman , 69410@debbugs.gnu.org Received: via spool by 69410-submit@debbugs.gnu.org id=B69410.17419370435859 (code B ref 69410); Fri, 14 Mar 2025 07:25:02 +0000 Received: (at 69410) by debbugs.gnu.org; 14 Mar 2025 07:24:03 +0000 Received: from localhost ([127.0.0.1]:59880 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tszOl-0001WR-9n for submit@debbugs.gnu.org; Fri, 14 Mar 2025 03:24:03 -0400 Received: from sendmail.purelymail.com ([34.202.193.197]:54992) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tszOh-0001Vp-9y for 69410@debbugs.gnu.org; Fri, 14 Mar 2025 03:24:00 -0400 DKIM-Signature: a=rsa-sha256; b=zuydARSr05gI7D7Fnwg6gN60VFOeXh4eAqCYT9zsQLIrFrWRzqw2lSA7Q1lG+KAxmSjl2BQNDEXFpSIaln8AL1cQjcyA/9u9AXLyPeWChwOZrwvzjo1bxa2+wdtn/hNygntAxwc1qPkFaeTcUAsv0tknC3FIi4RKlfgOl61Wqkxe+uZwN0hz7HtuelIr01f3+tzAlbYIMiG/HGrzAD3++2gHvKAwVxaaSjFQcmIqRkoPq0yXjM7+00WRwuVmQObDnoronxuuCkoKaZKA62jSb5CXjHanAT6uoDB5Z8/riGHsyo9BIxNE5A3OE26ChU1xw1XSDx1LSZgwxZzsHRZ3ew==; s=purelymail1; d=spwhitton.name; v=1; bh=JjYTbvG/jKc5s9D+x7bZiPnY7IG2qEfYOMW/0s/Azpc=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=t2gyQ2TB62yVCfiEYu05d3Jr+GEnJAR+YULdNquXzJgLRfiLQBmx/ESSFOgmX+L4VW3XCa0WBrelQ05WfcuB2EhTAtXYc5omZ7gqQYo6TjxD7Oc2BuurPXF+nM4m0gHar+RfpJ1by33/c057qLiyus+vIM5CfM7qpka6NaU+4sqgKugk0XVilctXDOtl/UjfKLzZ5v9Rs/9N95edsRHA2qFhONoUTw22pj+PTbifrXB/3ezf3HQk/mf2WGrEjOSgCPMojcjq0QaFEpPnideZcBibI3ed1PXYfAq6uAmy7ZCHFI1o9PltYwwlxgZyCrgoPLPyySC4POngW1SYqDxIJQ==; s=purelymail1; d=purelymail.com; v=1; bh=JjYTbvG/jKc5s9D+x7bZiPnY7IG2qEfYOMW/0s/Azpc=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 69410@debbugs.gnu.org Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1224624742; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Fri, 14 Mar 2025 07:23:52 +0000 (UTC) Received: by melete.silentflame.com (Postfix, from userid 1000) id DE00B7ED23F; Fri, 14 Mar 2025 15:23:48 +0800 (CST) From: Sean Whitton Date: Fri, 14 Mar 2025 15:23:48 +0800 Message-ID: <87y0x8ulbv.fsf@melete.silentflame.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Tony acknowledged something that might be useful but it seems like Philip, the package-vc maintainer, doesn't think there are any appropriate changes to make. Is my read correct? In that case I think we should close this as wontfix? -- Sean Whitton