[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alain Schneble
Subject: Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added
Date: Sat, 8 Oct 2016 12:25:17 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt)

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

> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]