Re: GNU ELPA and package.el

[Achim Gratz <Stromeko@nexgo.de>]

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