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: Alain Schneble
Subject: Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added
Date: Sat, 8 Oct 2016 13:41:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Alain Schneble <address@hidden>
>> CC: Phillip Lord <address@hidden>, <address@hidden>,
>>      <address@hidden>
>> Date: Sat, 8 Oct 2016 12:57:54 +0200
>> 
>> 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?
>
> I don't know; maybe none at all.  I just wanted to be exhaustive, and
> the last item is different in that it updates the files in the tarball
> with the ones on ELPA.

Aha, thanks for clarifying.

>> 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.
>
> The Right Way of doing this is exactly as we do with the likes of
> charscript.el: edit the files that are their sources, in this case the
> file in the ELPA repo, then commit the changes there, and finally
> re-download them into the Emacs tree.  We are doing that all the time
> with generated files.

Do you mean committing the files with or without pushing to the remote
git repo?  I guess you mean including a push?  That would work of
course, but might be a bit cumbersome.  I guess somentimes one wants to
try it out prior to pushing to the remote.  (Of course, changes can
always be eval'ed in the running Emacs, regardless in which file they
are...).  Also, there must be a way to properly deal with branches.  Is
that supported by the workflow used with charscript.el?

Or if you meant without pushing at all, then none of the above would be
an issue, I think.  But the logic of getting ELPA core packages into the
Emacs directory tree would be a bit different, as it would have to get
the files from the local git clone.

Alain




reply via email to

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