Re: [Emacs-diffs] feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Alain Schneble <address@hidden> writes:

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

Not if we are using package.el to make the packages available. It is
package.el which sets the load path, loads the autoloads file, that sort
of thing.


>> 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 ;)

"user" here means "developer" - it doesn't make any difference for the
end user. For the developer, yes, it's probably easier for those who are
used to the lisp in the core, but harder for those who are used to
package.el format.



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

So would I, but that is not the directory layout for core. It is for package.el.

Phil