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: Fri, 30 Sep 2016 22:02:01 +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:
>
> At the moment, no, there isn't (at least not until the -pkg.el file is
> built).
>
>> Or use a file-local variable as Eli proposed? So I think we get it
>> nearly for "free". Or what do you mean by "keeping track of"?
>
> Just what you think, yes. We need to distinguish between the two
> formats. Putting them different directories, with different make files
> is a trivial way to achieve this.

FWIW, if there is a strict naming and folder mapping convention, just by
looking at the list of ELPA-in-core package _names_, one can derive
which files belong to which package.  So an explicit "tagging" might not
even be required at all.

But I do not really understand when exactly we have to distinguish
between the two formats.  Isn't it more like a one way extraction of
ELPA package into core and then the job is done and distinction doesn't
really matter anymore?

> Just for what I say. Having the two package systems in different
> top-level (or lower-lever) directories makes life easier. Copying files
> from package.el format locations in core format would be possible but,
> again, complex.

Yes, there is an extra move files/directories step involved.  But I
think it finally makes the _user's_ life easier ;)

>> Whether it's confusing or not -- well you will find arguments against
>> all proposed approaches.  I think d) is easier because it doesn't divide
>> elisp source code based on where the sources actually come from.
>
> I understand that. But, unless we do something complex tests,
> documentation, icons, subsidiary files and so forth will be in different
> places for one style of packages than for the other.

Don't know if that really matters.  Well it would if we wouldn't put
resource files such as icons, subsidiary files and so forth at the same
location as the *.el files.  As packages may use 'load-file-name' to
locate these files.  FWIW, I would keep them next to the *.el files.

Alain




reply via email to

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