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

[Radon Rosborough <radon.neon@gmail.com>]

> > > I don't think it will be significantly better.
> >
> > Can you provide justification for this? Such justification would take
> > the form of explaining why the advantages I listed are not valid, or
> > there are disadvantages that I missed.
>
> Both solutions are problematic and cause user annoyance.  I don't know
> how else to explain that.
>
> > > I myself cannot say I like the idea of Emacs creating an init file
> > > in the user's home directory.
> >
> > Do you like the idea of Emacs modifying the user's init-file
> > automatically, even if it already exists? If not, then do you agree
> > that my proposal at least reduces the problem?
>
> I don't like either of these, but again, I see no significant
> improvement, if at all.

It would be best to start with explaining in what situation my
proposal would cause user annoyance. Explaining specifically why the
automatic creation of an init-file is "problematic", apart from the
fact that you don't like it, would be a good next step.

Even better would be explaining why each of these four specific
reasons that my proposal improves on the current situation are
invalid:

  * Emacs does not automatically modify the user's init-file without
    asking. This eliminates a wide range of unfortunate and annoying
    side-effects, as you can imagine. Here are two:

      - People who don't want to use package.el don't get irrelevant and
        damaging (because of duplicate loading) code stuck in their
        config.

      - People who use package.el but call (package-initialize) in some
        file other than init.el will not get a superfluous call inserted
        (which might well break their config) if there happens to be an
        error during init.

  * In future, if we wish to improve the "out-of-the-box" user
    experience, we can do so without needing to break backwards
    compatibility, by simply modifying the template init-file.

  * It's consistent with standard best practices. All other programs
    which have a similar problem to package.el solve it by providing a
    template config file. The reason that all these other programs avoid
    modifying their config files is the same reason that package.el
    should avoid modifying the init-file as well.

  * It will never accidentally place (package-initialize) in the wrong
    place, which happens frequently with the current system and defeats
    the entire purpose of an aggressive hack to make things "just work".
    In fact, the current system *always* places (package-initialize) in
    the wrong place if the user happened to customize anything like
    `package-archives' in their init-file (which is extremely common,
    and I'd go so far as to say that *not* doing this is the uncommon
    case).

> I realize that this is just a repetition of what I said above, but I
> don't really understand what needs to be explained here.  If this is
> still unclear, perhaps you should ask more specific questions.

The current (package-initialize) loads the autoload files for all
installed packages (or just a subset, if `package-load-list' was
modified). It also adds those packages' directories to the load-path.
At least this is my understanding.

You suggested continuing to do these operations after loading the
init-file, but also to

> add another call at a proper place in startup.el to do whatever
> needs to be done before the user init file is processed.

Please explain what exactly needs to be done before the user init-file
is processed, and how doing this would allow both package.el
configuration and package configuration in the init-file without the
prescence of an explicit (package-initialize) call.