[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Friendly discussion about (package-initialize)

From: Clément Pit-Claudel
Subject: Re: Friendly discussion about (package-initialize)
Date: Fri, 11 Aug 2017 10:03:19 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

On 2017-08-11 03:14, Mark Oteiza wrote:
> Sure, `package-load-list' is arguably less likely to be changed, but
> tons of people change `package-archives' to use 3rdp packages, and these
> users are at the core of the argument for this misfeature.  Either
> variable being in the wrong position relative to package-initialize
> breaks things.

I'm not well-versed in these issues, so apologies if this is misguided. Would 
the following work?

* Call package-initialize *before* loading init.el
* Add two new functions package-set-load-list and package-set-archives that 
call package-initialize after setting the relevant variables.  This could be 
extended to any other variable that affect the behavior of package-initialize.  
If there are many, a larger package-configure function or macro might be more 

The hope it to settle this package.el trouble by providing something that works 
without requiring users to add a package-initialize form in their .emacs.

I can see the following downsides, and potential fixes:

* What about existing configurations? Presumably they currently call 
package-initialize, so this wouldn't break things for them.
* What if people set those variables directly and expect things to work? We 
could add watchpoints on these variables, or keep the package-initialize call 
that runs after loading init.el.  I don't think people would expect setting a 
variable to do much, so I don't think thatwould be much of an issue.
* What about performance? Won't these extra (implicit) calls (from 
package-set-archives etc.) make things slow? We could make them reload only 
what's needed. IOW, package-set-archives would be akin to (progn (setq 
package-archives …) (package-refresh)) with package-refresh a new function that 
builds atop a previous package-initialize call.
* What if I *don't want* to use package.el at all? We could recognize a special 
dot-file in .emacs.d to disable package.el entirely (say, .nopackage).

On the upside, we get a working configuration for everyone without having to 
require or insert package-initialize calls in the user's config.


reply via email to

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