From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#71356: use-package doesn't load org from elpa Date: Mon, 10 Jun 2024 15:14:34 +0300 Message-ID: <861q559eqd.fsf@gnu.org> References: <86plsvk57o.fsf@gnu.org> <86ed9aip6z.fsf@gnu.org> <87ed9abnqn.fsf@posteo.net> <868qziifzd.fsf@gnu.org> <87msnt1gkf.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28685"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 71356@debbugs.gnu.org, acorallo@gnu.org, paaguti@gmail.com To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 10 17:13:25 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1sGgi4-0006zV-74 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Jun 2024 17:13:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sGghU-0000ED-JP; Mon, 10 Jun 2024 11:12:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGghS-0000CD-9R for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 11:12:46 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sGghR-0007X1-Ua for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 11:12:46 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sGghi-0003eF-Rh for bug-gnu-emacs@gnu.org; Mon, 10 Jun 2024 11:13:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Jun 2024 15:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71356 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 71356-submit@debbugs.gnu.org id=B71356.171803234113893 (code B ref 71356); Mon, 10 Jun 2024 15:13:02 +0000 Original-Received: (at 71356) by debbugs.gnu.org; 10 Jun 2024 15:12:21 +0000 Original-Received: from localhost ([127.0.0.1]:40746 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGgh2-0003bv-LA for submit@debbugs.gnu.org; Mon, 10 Jun 2024 11:12:21 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sGggw-0003Zs-Do for 71356@debbugs.gnu.org; Mon, 10 Jun 2024 11:12:15 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sGdv3-0004Ce-AV; Mon, 10 Jun 2024 08:14:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jKNAyxVJO9rMAMmK5NcB/EIQR15vNqobc9Bj/del3Gg=; b=U5Y7HRrmRX2m bamkc0Wd6ijWEjnVe5i8bS1ZHZT1R6wxBpLjh2higDdWyZYMmP5syiBIDi/yW8kRAw8n80SlkmRMp zl5nNswjl8G/cDeMjABvlQlsayb1OEVu0QaiYi5PNl/bfrMObFhTmGu9tei4Mee4EKTmFiRYFCCGW KxEfi/mIIK0xubmwTQNIdtGaQUdzybzvtgkyQMACJN1+44aZHw+MXo2yItbnueM5jzhsOaOA1tWAz PJGi5V2Sy3M+zxJpwB1S7VsKjJDMWOOuA7sBYoFXfaQNcfET0BPYcSG5Hq9ZCLomKj8T9tSgtm6ky 5br5BuwMz9HzFLQkdVRR6Q==; In-Reply-To: <87msnt1gkf.fsf@posteo.net> (message from Philip Kaludercic on Mon, 10 Jun 2024 06:02:08 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:287039 Archived-At: > From: Philip Kaludercic > Cc: paaguti@gmail.com, acorallo@gnu.org, 71356@debbugs.gnu.org > Date: Mon, 10 Jun 2024 06:02:08 +0000 > > >> IIUC the feature would be that if a use-package form has a > >> > >> :pin gnu > >> > >> argument, then this is an indication that we want to install the package > >> from GNU ELPA, disregarding the fact that Emacs already has a built-in > >> version of the same package. Sort of a package-local version of > >> `package-install-upgrade-built-in'. > > > > I'm not sure. People tend to copy/paste recipes from the Internet > > without really understanding what they do. I think a simple :pin > > should not be sufficient, we need some specialized keyword (in > > addition to supporting package-install-upgrade-built-in). > > To me :pin would make perfect sense, as it explicitly expresses what > archive we want to follow for package upgrades. Bitter experience should have taught us that what makes perfect sense to us does not necessarily make such perfect sense to others. Which is why we don't like to make incompatible changes in behavior even though the new behavior sounds like a definite TRT to us. Let me remind you that similar arguments were voiced to make package-install-upgrade-built-in be the default. We didn't. So I'd like us to trod cautiously here, abiding by the same logic as package-install-upgrade-built-in. If nothing else, that's consistent with other methods of upgrading built-in packages. > >> I am not familiar with the use-package code, but it seems like we could > >> implement this generally in package-install, by checking > >> `package-pinned-packages'. > > > > I would prefer not to introduce another indication of whether built-in > > packages should or should not be upgraded. If we do, we will next > > need to decide which one "wins" when they contradict each other. > > One idea would be that use-package would check :pin and then > conditionally bind `package-install-upgrade-built-in' when invoking > `package-install'. That being said, I am not a fan of the user option > any way, and wouldn't mind if we came up with a cleaner solution. Cleaner that package-install-upgrade-built-in? Why is that "unclean"? Given that users may or may not want the built-in packages to be updated en-masse with their usual updates, a user option lets everyone have what they prefer, so it's the cleanest possible solution, IMO.