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: Thu, 06 Jun 2024 12:21:26 +0300 Message-ID: <868qziifzd.fsf@gnu.org> References: <86plsvk57o.fsf@gnu.org> <86ed9aip6z.fsf@gnu.org> <87ed9abnqn.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32998"; 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 Thu Jun 06 11:22:02 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 1sF9Jp-0008O3-8q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 06 Jun 2024 11:22:01 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sF9Jf-0003V5-8M; Thu, 06 Jun 2024 05:21:51 -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 1sF9Jc-0003Tv-2K for bug-gnu-emacs@gnu.org; Thu, 06 Jun 2024 05:21:48 -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 1sF9Jb-0004pw-QA for bug-gnu-emacs@gnu.org; Thu, 06 Jun 2024 05:21:47 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sF9Jq-0000Tp-9d for bug-gnu-emacs@gnu.org; Thu, 06 Jun 2024 05:22: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: Thu, 06 Jun 2024 09:22: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.17176657161826 (code B ref 71356); Thu, 06 Jun 2024 09:22:02 +0000 Original-Received: (at 71356) by debbugs.gnu.org; 6 Jun 2024 09:21:56 +0000 Original-Received: from localhost ([127.0.0.1]:52352 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sF9Jk-0000TN-87 for submit@debbugs.gnu.org; Thu, 06 Jun 2024 05:21:56 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sF9Ji-0000T9-PH for 71356@debbugs.gnu.org; Thu, 06 Jun 2024 05:21:55 -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 1sF9JO-0004my-RL; Thu, 06 Jun 2024 05:21:34 -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=qhABnRPPQfbnwettiVR0jOO2VK5vf3QNmyn1LnOdR5M=; b=q6MFHmyah6/W YG0Z4yJJwbD4Tl2BeMogeVFVf/tNh5nf78QbDgfVp6/cSGFs2BorVX4fbt5mhYnAmwyfsPXH16sV/ hOLUazOenNjaOvin+FkSwvrF/kbIXVT5PBFq5xFna+N/72kp3XMIs+/mdTupIxqhpRPArIJAKQNAs qnyTEHDpAmyz2fv/GHUBskylp2HY3HBLRmYQGUXiAsZVPl0hUYeBHZZjYgJBT4tR8hxaWdhBevbdj 8cfbSnnAY16sHxIsQBKY918b+jh3XdPMKN8JJ4Lcmzhc7ID0keLwYpVinqg21rfKrUIhu/YP/CXNR cjhqRpVqELQNRWgDYizV7w==; In-Reply-To: <87ed9abnqn.fsf@posteo.net> (message from Philip Kaludercic on Thu, 06 Jun 2024 06:15:44 +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:286675 Archived-At: > From: Philip Kaludercic > Cc: Pedro Andres Aranda Gutierrez , acorallo@gnu.org, > 71356@debbugs.gnu.org > Date: Thu, 06 Jun 2024 06:15:44 +0000 > > Sorry for the delayed response; I don't think that has to be expected. > While use-package can utilise package.el for package management, my > impression is that it is at liberty to be more flexible/declarative. Doesn't use-package utilize package.el already? If not, how does it handle installation and upgrades? by its own code? > > Do you have package-install-upgrade-built-in set non-nil? If not, can > > you set it non-nil and try the recipe again? > > I have tried it out myself, and it doesn't appear to do anything. The > issue looks like that `package-installed-p' doesn't respect > package-install-upgrade-built-in or :pin. We should fix that, I think. If package-install-upgrade-built-in is non-nil, use-package should upgrade built-in packages. > > As for a feature request: what exactly is the feature requested here? > > Are you saying that use-package should automatically upgrade built-in > > packages? If so, I don't think this will fly, since it would mean > > inconsistencies with package-install. > > 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). > 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.