From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA and package.el Date: Mon, 08 Apr 2019 21:39:40 -0400 Message-ID: References: <20180823213418.GA32596@ACM> <83lg8w9mt2.fsf@gnu.org> <871saoc70o.fsf@gmx.de> <87wosebzur.fsf_-_@gmx.de> <87tvnh9yg6.fsf@gmx.de> <8736myq6wo.fsf@gmx.de> <87y34o704v.fsf@Rainer.invalid> <87mul2p9m0.fsf@Rainer.invalid> <87sgut7m3o.fsf@Rainer.invalid> <87imvoz8j9.fsf@Rainer.invalid> <87tvf8fdp4.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="193392"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 09 03:40:34 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hDfkY-000oCC-O2 for ged-emacs-devel@m.gmane.org; Tue, 09 Apr 2019 03:40:34 +0200 Original-Received: from localhost ([127.0.0.1]:33477 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDfkX-0006cS-Oi for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 21:40:33 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDfjx-0006c8-2Z for emacs-devel@gnu.org; Mon, 08 Apr 2019 21:39:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDfju-000480-Qs for emacs-devel@gnu.org; Mon, 08 Apr 2019 21:39:56 -0400 Original-Received: from [195.159.176.226] (port=39370 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hDfjq-00043X-UG for emacs-devel@gnu.org; Mon, 08 Apr 2019 21:39:52 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hDfjp-000nFT-1f for emacs-devel@gnu.org; Tue, 09 Apr 2019 03:39:49 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:Q8f+shvCxEehGqLWKlbRxAnXMEQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:235144 Archived-At: > Well, Org would have to move it's main file out of the way and replace > it with a generated one just to accomodate ELPA. That's one choice. Adding the "Version: ..." directly in the current org.el would also work OK in practice, even if you find it distasteful in theory. > That was (very) briefly contemplated, but it still doesn't make sense. > What if the next package archive wants it someplace else? Yes, what if. What if the next package archive decides that `org.el` should be the name of the Org-mode file that describes the package? I think you'll be better off crossing this bridge when/if you get to it. >> I'm pretty sure it's much easier for Org to put the version where GNU >> ELPA expects it than for all elpa.git packages to change where they put >> their version. > Why is this more logical than using either the file that defines the > package (org-pkg.el) or the file that normally gets generated for Org > for this purpose (org-version.el)? "Logical" is probably not the right way to describe it. Currently, we indeed exceptionally use org-pkg.el, but it's the one and only package which does that, so I'd like to get rid of this ad-hoc hack in the build scripts. The status-quo is on your side, tho, so I guess I'll have to "suck it up" ;-) >>> What I'm trying to say is that users might easily find themselves in the >>> situation that requires them to ignore part of their system installation >>> (which they can't do anything about because somebody else provides it). >> Right, but I don't see what package.el can do about it. > Telling them about all available versions and where they come from would > be a start. It already does tell them about all versions. So IIUC you're asking the `list-packages` command to display somewhere the package location. My setup is a bit weird, so my tests aren't very conclusive, but it seems that there's already some indication of the complete directory name where the package was found, tho it's not displayed in all cases (and it's sometimes labeled as "external"). I'm not very familiar with the package UI so I'm probably not the best person to fix this, but it sounds like a good idea, indeed. > This would likely entail to name the various local package > directories, so they show up by name like the different package archives > already do. Oh, you're thinking of displaying them directly in the package list rather than only in the *Help* buffer where an individual package is described? Yes, that would require more work to be able to name those directories, but it would be fairly natural to re-use the "archive" column for that. > What I meant was that the order of the various local package sources > (and possibly the order of foreign package archives) could be used to > indicate the general preference order, much like load-path does. Indeed, that sounds fairly natural. I'm not sure how easy it would be to do it, tho. Also not clear would be the interaction with built-in packages: e.g. it's important for the cl-lib-1.0 built-in packages to take precedence over user-installed cl-lib-0.5. >> If we made package-user-dir packages always take precedence over >> system-wide packages, then this case is covered, right? > Yes, for this case this should work. But the general precedence will > sometimes need to be modified on a per-package basis. Installing or not installing the package into package-user-dir does give you the per-package control. > The tricky question is what package menu should be doing if the user > then asks for updates. Any exception should be sticky unless > explicitly lifted, but it's not really recorded what was a user > decision and what was the result of automatic resolution (other > package managers keep tabs on this for exactly that reason). We do record installation decisions in package-selected-packages. > Ideally anything not needed for dumping Emacs should be a proper package > (whether it's maintained in a different repository or not is orthogonal > to that). For some definition of "ideal", yes. But there are downsides as well. Stefan