Re: GNU ELPA and package.el

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

> 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