Re: feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Lars Ingebrigtsen <address@hidden> writes:

> Anyway, I've been trying to follow this discussion, and I just don't
> seem to get what the problem is.
>
> Today, a package is (basically) some .el files in a directory.  We want
> to extend this paradigm to have in-tree packages that can be updated.

I don't. I want to have a parallel tree of in package.el format.
Updating (or, rather, outdating since we are not changing files) comes
for free.


> Isn't the obvious solution to have a manifest in each package that says
> what .el files are part of that package?
>
> That is, if we have in in-tree package foo, that consists of the files
> lisp/foo.el and lisp/image/foo-images.el, then the manifest for foo-0.5
> (included in the emacs-26.1 distribution) will be:
>
> '("lisp/foo.el" "lisp/image/foo-images.el")
>
> Now, if the user has updated to a newer version from GNU ELPA, then
> those files will land in ~/.emacs.d/elpa/foo, and the manifest will say
> that the files belonging to version foo-0.6 will be
>
> '("elpa/foo/foo.el" "elpa/foo/foo-new-images.el" "elpa/foo/foo-me-more.el")

Yes, although, this is not just the .el files. We also have the info and
etc files which need similar treatment.


> Now, package.el knows that the user wants foo-0.6, so it prepends that
> directory to load-path.  In addition, it also has to blacklist all .el
> files from previous versions of the package that are visible, which
> will, in this case, be the files in the manifest from the build-in
> version 0.5.  So it'll add '("lisp/foo.el" "lisp/image/foo-images.el")
> to a new variable load-path-blacklist, and saying `(require 'foo-images)'
> anywhere will fail with "cannot open load file".

Also, loaddefs.el. Currently, the in-tree foo-0.5 will have it's
autoloads dumbed into loaddefs.el (unless it's one of those packages
with it's own loaddefs). We'd also need to undefine all the autoloads
defined in there which relate to foo-0.5.

I think that there might be an issue with timing also. Say some one has
a .emacs like so:

(require 'foo)
(package-initialize)

Then I think that they will get foo-0.5 because package.el hasn't done
all the things you mention yet. Thinking quickly, this is an issue for
my solution also, and will require a careful solution.

> Am I missing something?

You have thought of most of the issues that came to mind for an in-tree
solution; we probably are both missing things. We won't know till it's
build.

Phil