Re: Calling (package-initialize) sooner during initialization

[Vasilij Schneidermann]

> We discussed this already.  There's the issue of configuring package.el
> before loading it and/or before calling package-initialize.

OK, I've checked again and sighted eight customization candidates in
package.el:

- package-enable-at-startup: Would be equivalent to the proposed
  environment variable.
- package-load-list: Needs to be configured before.
- package-archives: Needs to be configured before for
  non-interactive package installation.
- package-pinned-packages: Needs to be configured before for
  non-interactive package installation.
- package-user-dir: Needs to be configured before.
- package-directory-list: Needs to be configured before.
- package-check-signature and package-unsigned-archives: Can be
  customized afterwards

So, while setting the environment variable in my proposal would equal
the (setq package-enable-at-startup nil) trick in combination with the
necessary customization and (package-initialize) at a later point in the
init file, it would be clunkier than the status quo.

Another possible technical solution to this would be introducing an
extra configuration file containing the listed startup/package-related
options only that is read in before the init file.

Finally, to suggest a non-technical solution to this "problem" of new
users not knowing about (package-initialize) for the use of
functionality from packages they've installed from package archives, why
not improve existing documentation?

GNU ELPA's homepage is minimal.  Its documentation seems to be the
"Packages" section of the Emacs info manual.  Linking to it would be a
fair improvement opportunity.  MELPA's "Getting started" page explains
the need for and placement of (package-initialize) reasonably well,
perhaps an explanation of the gotchas involved would be useful.
Marmalade has an interactive walkthrough, yet doesn't mention
(package-initialize) at all.  Adding that part to its homepage would be
better than passing the responsibility to package developers getting
issues reported by users not aware of this.  I would generally be
interested in empirical evidence of the numbers and package archives
involved in such bug reports to see whether my suggestions are right on
the mark.