Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

[Alain Schneble]

address@hidden (Phillip Lord) writes:

> Alain Schneble <address@hidden> writes:
>>> Not if we are using package.el to make the packages available. It is
>>> package.el which sets the load path, loads the autoloads file, that sort
>>> of thing.
>>
>> After all, what would we gain from using package.el to do this
>> bootstrapping for the ELPA core packages?
>
> Packages in already in package.el format can be directly used within
> Emacs. This requires no changes in the file layout, and means that
> packages will only be built with a single system (i.e. both Emacs core
> and ELPA will be build with package.el).

Core libraries not from ELPA (e.g. url) will still be compiled using
non-package.el build.  So after all, we still have the "core library
build" approach.  Again, my point is to use that approach also for ELPA
core packages.  I would rather stick to that instead of introducing a
hybrid approach in Emacs core just to support ELPA core packages.

> As a secondary benefit, this means I can build and test an ELPA checkout
> directly as part of the Emacs build, which should be useful for finding
> regressions.

Sticking to the core directory layout wouldn't imply that this is not
possible.  We could again copy the files before the tests are run or
provide support for a development-time structure that more adheres to
the package.el structure.

>> If I understand correctly, finder.el does populate package--builtins
>> already today, based on the files and directories in ./lisp. Just
>> automatically fetching all ELPA core packages from the corresponding
>> git repository (or repositories?), extracting and moving files to the
>> proper Emacs directories wouldn't require any (or much) additional
>> logic on that level. Do I miss something here?
>
> If it all works, no. But I see no benefit from doing this.

I see the benefit that the release tarball directory layout will be
cleaner.

> It also, of course, means that files from ELPA would now be duplicated
> in core Emacs because they would have been copied. So, when developing
> Emacs, there would be version controlled .el source files and
> non-version controlled copied .el files in the same location. You would
> have to remember to edit the former, but not the latter.

I'm primarily concerned about changing the release tarball layout.
Again, if copying files really is a problem we could support a
development-time layout that removes this duplication.

>>> So would I, but that is not the directory layout for core. It is for 
>>> package.el.
>>
>> I would still move tests into ./test/automated/, for example.  And now
>> if I think of it, it would probably make sense to move resource files
>> (static data such as icons, schemas etc.) into ./etc/ and not into
>> ./lisp/?  Is that where such files of non-ELPA, built-in libraries are
>> put in Emacs today?
>
> Yes, resource files are in ./etc

Thanks.

Alain