Re: Calling (package-initialize) sooner during initialization

[Stefan Monnier]

> I generally feel uncomfortable about a tool automatically editing a file
> that I assume to have control over, but maybe that's fine.

We all do.  Yet that's also what custom.el does.

> A concrete problem I can think of is when one has some settings for
> package.el in their init file, then Emacs ends up putting
> (package-initialize) at the top, when it should be after the package
> related settings.  Is this not a problem?

Oh yes.  And there can be all kinds of other interesting cases.

> with a trick like this.  WTF?  It might be simple to implement, but
> conceptually it's rather confusing.

Well, conceptually it's simple as well, if you look at it from the
implementation point of view ;-)

> wrong (packages are automatically initialized after loading init.el if
> it hasn't been done there)

Actually, with the new code that auto-adds "(package-initialize)" to
~/.emacs, we should be able to get rid of this hack that calls
package-initialize if the .emacs didn't do so already (tho we'll need
to wait a little, for the usual compatibility reasons).

> and a sign of the package system being crudely bolted on top of
> existing machinery.  That's stinky engineering.

Welcome to the world of long-lived programs that need to live with
backward compatibility.

BTW, having a separate pre-package init file would also be stinky
engineering imposed by hysterical raisins.  Good engineering would
probably require re-thinking the whole customize-set-variables issue and
maybe also the semantics of defcustom.  I'd be happy if someone were to
try and do the work of figuring out what a clean design would look like,
so we'd at least be able to assess whether we can hope to get there from
here without too much pain.

> I hope I'm not coming off as religious.

This is Emacs we're talking about.

> Yes, this is a more involved solution, but it brings some structure into
> Emacs initialization with regard to the role of the package system, and
> its interaction with Customize.

Right, and that's exactly what I don't want: I don't want to impose an
arbitrary structure that happens to suit the current needs.

Tricky dependencies between setting vars and loading their packages can
also exist within customize-set-variables without the existence of package.el.

> think it should be fine to leave that be and only load default.el and
> site-start.el after package initialization.  Or can anyone think of

The difference between site-start.el and default.el is that one is
loaded before ~/.emacs and the other after.


        Stefan