From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA and package.el Date: Mon, 08 Apr 2019 22:24:07 +0200 Organization: Linux Private Site Message-ID: <87tvf8fdp4.fsf@Rainer.invalid> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="247119"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 08 22:24:44 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 1hDaot-00127z-9C for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 22:24:43 +0200 Original-Received: from localhost ([127.0.0.1]:58488 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDaos-0004WZ-38 for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 16:24:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56547) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDaok-0004WF-Hp for emacs-devel@gnu.org; Mon, 08 Apr 2019 16:24:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDaoi-00034C-I9 for emacs-devel@gnu.org; Mon, 08 Apr 2019 16:24:34 -0400 Original-Received: from [195.159.176.226] (port=34564 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hDaog-0002rD-CC for emacs-devel@gnu.org; Mon, 08 Apr 2019 16:24:32 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hDaoS-0011g0-TV for emacs-devel@gnu.org; Mon, 08 Apr 2019 22:24:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:kVmGHxDyrltzGnVOwlFuSDDVvDk= 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:235131 Archived-At: Stefan Monnier writes: >> 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. …revision controlled file on ELPA. > 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). 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 was (very) briefly contemplated, but it still doesn't make sense. What if the next package archive wants it someplace else? > 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)? For those packages that don't generate files falling back to the (usually single) file that names the package is OK, but why not look for {-pkg,-version,}.el in that order in general? >> 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. This would likely entail to name the various local package directories, so they show up by name like the different package archives already do. >> 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. That's what I was trying to avoid. If I remove the whole directory, I then need to add back anything I _do_ want from it. In more general terms, currently the user only has ability to do positive selection and I want her to have negative selection on the package level as well. >>> 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. 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. >>>> 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`). Yes. >> 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? Yes, for this case this should work. But the general precedence will sometimes need to be modified on a per-package basis. Which probably would still work via package-load-list. 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). >> 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. 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). It's probably not going to happen anytime soon, yes. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables