From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: Suggestion for package.el: atomic package-upgrade Date: Mon, 31 Jul 2023 06:45:20 +0000 Message-ID: <87o7js37gf.fsf@posteo.net> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18819"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: dqs7cp2e Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Jul 31 08:46:43 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qQMfz-0004l0-MQ for ged-emacs-devel@m.gmane-mx.org; Mon, 31 Jul 2023 08:46:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qQMes-00043n-9E; Mon, 31 Jul 2023 02:45:34 -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 1qQMep-00042B-I4 for emacs-devel@gnu.org; Mon, 31 Jul 2023 02:45:31 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qQMen-0007HV-He for emacs-devel@gnu.org; Mon, 31 Jul 2023 02:45:31 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id AB656240105 for ; Mon, 31 Jul 2023 08:45:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1690785921; bh=IXO3fjqsRnGmWMU/N+DKPci0sJM7oDULtkBOty0wdPs=; h=From:To:Cc:Subject:Autocrypt:Date:Message-ID:MIME-Version:From; b=NbzF5NBqdJ4g1pr7DN21H7iup5lobUOyu4nFHewd5CzULuuyYJjaKcc4GZG+wxsAu g/bVPDNPWgB/Kz5/vMouagAjTDoeQXSA4Z3AtAvFCgHZyzgBj+35IlTR/jE6JK+Fbg KRPyAu0Pd41DNqKAiC1u9c5XWTjqjvod3gWayy7H3nuYdCzFwGcNgbMTxy3xKSgLe1 TwCtJVcWQyJSSPKRdP/wYA5fXWngHHNgzXRoOpGElSjuYbb1FDOz+3oXeIaGB6G7SO uswrkIK7kdT8fwLqHJ28lnfBsG7TmIAXcP0wKnTVFSLUkZRd9nd7342Zei8LjKRfIY HikcBLHkWr+Dw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RDpds2nXgz6tsj; Mon, 31 Jul 2023 08:45:21 +0200 (CEST) In-Reply-To: (dqs7cp2e@gmail.com's message of "Mon, 31 Jul 2023 08:58:16 +0700") Autocrypt: addr=philipk@posteo.net; keydata= mDMEZBBQQhYJKwYBBAHaRw8BAQdAHJuofBrfqFh12uQu0Yi7mrl525F28eTmwUDflFNmdui0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiWBBMWCAA+FiEEDg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwMFCQHhM4AFCwkI BwIGFQoJCAsCBBYCAwECHgECF4AACgkQ8xYDWXahwulikAEA77hloUiSrXgFkUVJhlKBpLCHUjA0 mWZ9j9w5d08+jVwBAK6c4iGP7j+/PhbkxaEKa4V3MzIl7zJkcNNjHCXmvFcEuDgEZBBQQhIKKwYB BAGXVQEFAQEHQI5NLiLRjZy3OfSt1dhCmFyn+fN/QKELUYQetiaoe+MMAwEIB4h+BBgWCAAmFiEE Dg7HY17ghYlni8XN8xYDWXahwukFAmQQUEICGwwFCQHhM4AACgkQ8xYDWXahwukm+wEA8cml4JpK NeAu65rg+auKrPOP6TP/4YWRCTIvuYDm0joBALw98AMz7/qMHvSCeU/hw9PL6u6R2EScxtpKnWof z4oM Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:308216 Archived-At: dqs7cp2e writes: > The current `package-upgrade' from package.el delete old package > before installing the new one. This can be problematic if the user > interrupt the process or if there is some network problems. > > `package-install' allow the same package to be installed if the > argument is `package-desc' instead symbol representing package name. > This allow package to be upgraded atomically. Is this a bad idea? No, I think this is a good idea, but it would be best if you could write a Git patch and send it to "bug-gnu-emacs@gnu.org" (you can use M-x submit-emacs-patch). > diff -u --label \#\ --label \#\ /tmp/buffer-content-4azQGZ /tmp/buffer-content-x8FLpt > --- # > +++ # > @@ -2275,16 +2275,20 @@ > package using this command, first upgrade the package to a > newer version from ELPA by using `\\\\[package-menu-mark-install]' after `\\[list-packages]'." > (interactive > - (list (completing-read > - "Upgrade package: " (package--upgradeable-packages) nil t))) > - (let* ((package (if (symbolp name) > - name > - (intern name))) > - (pkg-desc (cadr (assq package package-alist)))) > - (if (package-vc-p pkg-desc) > - (package-vc-upgrade pkg-desc) > - (package-delete pkg-desc 'force 'dont-unselect) > - (package-install package 'dont-select)))) > + (list (intern (completing-read > + "Upgrade package: " (package--upgradeable-packages) nil t)))) > + (let* ((name (if (symbolp name) > + name > + (intern name))) If you always intern the package name, you don't need this check anymore. On the other hand, you don't need to intern the name, because of this check, and I think it is better to keep it because that gives the user more flexibility when invoking the function. > + (old-pkg-desc (cadr (assq name package-alist))) > + (new-pkg-desc (cadr (assq name package-archive-contents)))) > + (if (package-vc-p old-pkg-desc) > + (package-vc-upgrade old-pkg-desc) > + (unwind-protect I am wondering if unwind-protect is the best approach here, or even necessary. Wouldn't something like --8<---------------cut here---------------start------------->8--- (when (progn (package-install new-pkg-desc 'dont-select) t) (package-delete old-pkg-desc 'force 'dont-unselect)) --8<---------------cut here---------------end--------------->8--- have the same effect? My reasoning is that we are not actually cleaning anything up in the UNWIND-FORMS, but just checking if the `package-install' was not interrupted, right? > + (package-install new-pkg-desc 'dont-select) > + (if (package-installed-p (package-desc-name new-pkg-desc) > + (package-desc-version new-pkg-desc)) If you check the definition of `package-installed-p', you will find it does not use MIN-VERSION if the first argument satisfied `package-desc-p', which makes sense because with a concrete descriptor, we can unambiguously check if a specific package version has been installed (the implementation just checks if the expected directory exists). Also, perhaps consider using `when' here. I argue that it looks better in imperative code where the return-value is not of interest. > + (package-delete old-pkg-desc 'force 'dont-unselect)))))) > > (defun package--upgradeable-packages () > ;; Initialize the package system to get the list of package > > Diff finished. Mon Jul 31 08:22:46 2023