Re: GNU ELPA and package.el

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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 <pkg>.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