Re: feature/integrated-elpa 4f6df43 15/23: README added

[Phillip Lord]

Eli Zaretskii <address@hidden> writes:

>> From: John Wiegley <address@hidden>
>> Cc: Eli Zaretskii <address@hidden>,  Andy Moreton <address@hidden>,  
>> address@hidden
>> Date: Mon, 17 Oct 2016 16:09:15 -0700
>> 
>> PL> I think it's decision time. I am happy to carry on a little further with
>> PL> the package.el based approach that I have outlined, fixing the one
>> PL> significant issue with it and then I will stop. If you don't want to go
>> PL> this way, that's fine.
>
> Sorry, I don't understand the kind of decision that is being
> requested.  I understand that one alternative is that you "carry on a
> little further" with your approach, although I'm vague about the
> details of that, or what is your goal.

Complete the code that I have started. Three goals:

 - Use package.el to build (compile, generate autoloads) packages in
   during the build
 - Use package.el to initialize and load these during startup
 - Support testing of these packages during build.

With a secondary aim of:

 - Enable a built emacs to build and test all packages in ELPA whether
   they are core/tarball or not.

> But the other alternative is entirely unclear to me. What is it?


Erm, don't do this.

Or write something such as you have been talking about, by copying bits
of ELPA into core, otherwise (presumably) leaving the build alone.


>> At this time, I don't want to go "full package.el".  However, I'd like to
>> include it, since it's key to how users interact with ELPA-based packages.
>
> I don't think I understand what does "full package.el" mean.  However,
> package.el is already included, it's in lisp/emacs-lisp/.

I presume John means what I have discussed above.

>
>> I think Eli said it best:
>> 
>> EZ> We need to adapt package.el to the new needs. It was not written with
>> EZ> these goals in mind, so it needs to learn new tricks. Throwing it away is
>> EZ> not acceptable, but neither is blindly accepting its current assumptions,
>> EZ> which were not designed for the use case we are discussing.
>> 
>> So let's not move to "directory per package", but let's do support "properly
>> upgrading a package that came with the distribution".
>
> That's obviously fine with me ;-)  I just am not sure this is one of
> the alternatives that Phillip considers.

It's obviously difficult for me to think of better ways of achieving
this than my current proposal. There are probably worse ways of
achieving it, I am sure.

Phil