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 15:01:45 -0400 Message-ID: References: <20180821162043.GA3946@ACM> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="159308"; 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 Mon Apr 08 21:02:08 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 1hDZWv-000fGJ-CB for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 21:02:05 +0200 Original-Received: from localhost ([127.0.0.1]:57498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDZWu-0001HN-BI for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 15:02:04 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:37399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDZWl-0001HE-Ef for emacs-devel@gnu.org; Mon, 08 Apr 2019 15:01:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDZWk-0006nF-1c for emacs-devel@gnu.org; Mon, 08 Apr 2019 15:01:55 -0400 Original-Received: from [195.159.176.226] (port=39192 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hDZWj-0006mF-NC for emacs-devel@gnu.org; Mon, 08 Apr 2019 15:01:53 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hDZWi-000ezj-CK for emacs-devel@gnu.org; Mon, 08 Apr 2019 21:01:52 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:Y7LywqJNYPOMjUrb0ka3NqlHQNU= 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:235129 Archived-At: >> elpa.gnu.org generates the packages from the various branches of elpa.git. >> So I'm not sure where it should get its version info if not from version >> controlled files. > > As I said, I'll happily make an exception for ELPA as long as it's > hobbled to not allow a proper build and provide any number of extra > pre-generated files that make up for the difference. What I do not want > to do (Org maintainer override is possible) is to alter files from their > state in orgmode.git (i.e. if you delete the pre-generated files the > result should be identical to a checkout from orgmode.git). So you're OK with a convention of taking the version from one of the revision controlled files. Good, since that's what we do. IOW the only problem is an unlucky collision between the choice made by GNU ELPA (to take the version from .el) and the choice made by Org (to put the version elsewhere). 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. > I no longer have the test scaffolding in place that allowed me to check > for this across a number of Emacs versions. IIRC, the changes back then > addressed only that part of the problem that was immediate (i.e. the > package would either fail to compile or activate). I can easily come up with artificial cases that fail miserably with the current system, but that doesn't really help me figure out what is the best solution, because all the solutions I can think of also fail miserably in other artificial cases. So we'll just have to wait until concrete cases show up. >> Not sure in which way that's related to the issue of system-wide >> ELPA packages. > 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. > While it is an unlikely case, I think it should still be possible. Obviously, they can't override everything that the sysadmin might do, but they can easily remove the system-wide package directory from package-directory-list, so AFAIK there's nothing harder about package.el packages than about anything else the sysadmin might do. >> One way we could do this is to always prefer the user-installed version >> over the system-wide one (tho, this will inevitably be somewhat brittle >> since we actually don't truly know which directories are "user" and >> which are "system", we can only approximate it e.g. by checking if we >> have write access or by declaring that package-user-dir is the only >> user directory and all others are system-wide). > > The order of all package directories provides a hierarchy already and in > most cases the highest rung should provide the definite information. > That part is mostly working already, I think. Not that I know: package.el currently doesn't pay much attention to the order of directories in package-directory-list. It just gathers all the packages it finds there and activates the most recent version of each, by default. >>> More generally, being able to "delete" a package at any level (or making >>> it completely invisible) is immensely useful for testing. >> I still don't know what you mean by "delete" here. > s/delete/mask/ > Does that make more sense now? I'd be happy if you find a better word > for it. Ah, I see. Currently you can only do this by either disabling the package completely (i.e. all versions) or by explicitly selecting another version of that package (in both cases, this is done in `package-load-list`). > So, let's say the system has a package "Foo" installed and the user > wants to install and use an older version of that. If we made package-user-dir packages always take precedence over system-wide packages, then this case is covered, right? > Another useful case is to pretend the builtin package "Bar" wasn't > there, lets say for testing purposes. I think this is going beyond the purpose of package.el. To make it workable, we'd need to change the layout of Emacs's builtin files into many more directories, and I don't think we'll want to go there in general unless/until there's a really compelling reason for it. For the specific case of Org, we could arrange something. Indeed, the most logical arrangement for Org (arguably) is to remove it from emacs.git and only include it in tarballs as a "bundled ELPA package", in which case it should indeed be possible to control it via package-load-list like any other. Stefan