emacs-devel
[Top][All Lists]
Advanced

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

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


From: Phillip Lord
Subject: Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added
Date: Sun, 09 Oct 2016 21:38:40 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:
>> Packages in already in package.el format can be directly used within
>> Emacs.
>
> What do you mean by "directly used"?  Directly as opposed to what?

Without installation -- that is, as part of core 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).
>
> Why would the Emacs build require package.el to do anything at all?

Why not? It's a convienient way of building packages.

> And what kind of build do you have in mind here?  We have:
>
>   . build out of Git repo
>   . build of the release tarball as distributed from ftp.gnu.org
>   . build of the release tarball after updating some packages from ELPA

All of these, I think.



>> 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.
>
> ELPA packages should be logically part of Emacs, just in a different
> Git repo.  So this goal should be supported, of course.  But I don't
> understand why it would require using a separate directory tree for
> ELPA packages.


It enables the convienience of taking a directory containing a package
from ELPA and putting it within the Emacs build unchanged. This seems
clean and simple. It should also enable "git submodule/subtree" type
options.


>> It also, of course, means that files from ELPA would now be duplicated
>> in core Emacs because they would have been copied.
>
> ??? Copied from where to where?  And why?  I don't understand why they
> would need to be copied anywhere, they just need to be downloaded
> directly to where they belong in the Emacs directory structure.

Downloading is copying right?

>> So, when developing Emacs, there would be version controlled .el
>> source files and non-version controlled copied .el files in the same
>> location.
>
> We already have that; see charscript.el.  Why having some moe
> unversioned *.el files would hurt or be any different?

There are generated .el files in Emacs, and there are specific cases
where this is necessary, but it's not a great thing. Mostly, I think,
.el files should be source code. At the moment, it's only a few files.
Making this more common seems bad.

>> You would have to remember to edit the former, but not the latter.
>
> ??? Unversioned files can be edited to your heart's content, they will
> just be overwritten on the next update.

Yep, which is bad, if you didn't intend this to happen.

Phil





reply via email to

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