[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
- Re: feature/integrated-elpa 4f6df43 15/23: README added, (continued)
- Re: feature/integrated-elpa 4f6df43 15/23: README added, John Wiegley, 2016/10/18
- Re: feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/19
- Re: feature/integrated-elpa 4f6df43 15/23: README added, Andy Moreton, 2016/10/18
- Re: feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/15
- Re: feature/integrated-elpa 4f6df43 15/23: README added, Eli Zaretskii, 2016/10/15
- Re: feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/15
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added,
Phillip Lord <=
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Eli Zaretskii, 2016/10/10
- Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Alain Schneble, 2016/10/08
Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added, Phillip Lord, 2016/10/03