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: Fri, 30 Sep 2016 17:17:29 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)

Alain Schneble <address@hidden> writes:

> address@hidden (Phillip Lord) writes:
>
>> Alain Schneble <address@hidden> writes:
>>>
>>> There's also d) where an elpa package would just go into it's
>>> corresponding directory under EMACS/lisp, e.g. EMACS/lisp/org if org is
>>> an elpa package.  Of course, there's a chance of name clashes here, but
>>> both GNU Emacs and GNU elpa are under the same control IIUC.
>>
>> Would require us to keep track of which packages are package.el format
>> and which packages are not, spread throughout multiple directories. As
>
> It should be rather easy to have a convention that can reliably be used
> to derive whether a given file or directory is in package.el format.
> Maybe there's already one?

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.



>> well as making the build a PITA (and fragile when we forget to update
>> the list), it would be confusing for the developers who would have to
>> remember two different sets of package structures.
>
> I can't judge the build part of this, but I don't really see why it's a
> PITA.  I also don't see what we would have to update additionally in
> this layout that we wouldn't have to in a), b) and c).

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.

> 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.

> When I looked into GNU Emacs sources the first time, I very much
> appreciated the IMO minimalistic directory structure.  I would try to
> not loose it if I could.


Yes, I can appreciate that.

Phil



reply via email to

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