Re: Summary and next steps for (package-initialize)

[Stefan Monnier]

>> Calling it before ~/.emacs means that package-initialize is done before
>> the user got a chance to configure package.el.  So we need'd to provide
>> some way to reproduce the behavior you can currently get by setting
>> various package.el vars before calling package-initialize.  E.g. we
>> could let a second call to package-initialize de-activate previously
>> activated packages and activate previously not activated packages.
> Would a ~/.emacs.d/.package-initialize.el file, to be read by
> package-initialize before it does anything else, be a better
> alternative for configurations that must be done before
> package-initialize is called?

To me, it'd be a worst case fallback if we can't find a better solution.

> Or maybe you have some other alternative ideas for how to make this
> happen?

Nothing very concrete yet, no:

- Change package-initialize so it keeps track of what it activated and if
  called a second time, perform a diff between what was activated before
  and what should be activated now and based on this activate the new pkgs
  and deactivate the excess ones?

- Process ~/.emacs specially so it can start with a special construct
  (with-early-config ...)

I've had other ideas, but they generally suck one way or another.


        Stefan