[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:57:54 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt)

Eli Zaretskii <address@hidden> writes:

> 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

What is the difference between the last and the second last point?

>> 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 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.
>> 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?
>> 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.  We successfully deal with
> this with the generated files, I see no reasons why we couldn't do the
> same with ELPA packages.

AFAIU, Phillip is concerned about the development process of ELPA core
packages.  While developing such a package, one wants to edit the
git-controlled files directly and probably also load these files instead
of the (git-uncontrolled) ones in the proper Emacs core location, where
they would reside at least in a tarball release.


reply via email to

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