Summary and next steps for (package-initialize)

[Radon Rosborough]

SUBJECT: Summary and next steps for (package-initialize)
FROM: address@hidden
TO: address@hidden

Hi all,

Last week I posted an inquiry [1] about package.el's auto-insertion of
code into the init-file. Six people weighed in, but no definitive
conclusion was reached. I would like to propose concrete next steps,
summarizing relevant parts of the discussion in the process.

==> The proposal

The `package--ensure-init-file' logic will be removed, and package.el
will not ever directly modify the user's init-file. However, if Emacs
is started with no init-file, then a default one will be generated and
loaded (except in 'emacs -Q'). This template init-file would include a
call to (package-initialize) and some comments explaining that package
configuration must be put after (package-initialize).

==> The disadvantages of this proposal

* If somebody (1) has an existing init-file, (2) uses package.el to
  install a package, (3) adds configuration code directly to their
  init-file, (4) fails to read the documentation about the need for
  `package-initialize', and (5) has not used package.el in the last
  year or two, then their package configurations will not work.

  I argue that this specific use case is virtually nonexistent. In
  particular, the vast majority of people already have
  (package-initialize) in their init-file due to the previous behavior
  of package.el, and new users will get to use the template init-file.

  Thus, I do not think this is a real disadvantage. Please tell me if
  you disagree.

* Emacs is creating a whole file without being asked.

  I argue that the current behavior is worse in this regard than the
  proposed behavior. The current behavior is that user-created files
  are edited automatically by Emacs. The proposed behavior is that
  nonexistent files are created automatically by Emacs. It seems clear
  to me that automatic file creation is much safer than automatic file
  editing.

  Thus, I do not think this is a real disadvantage. Please tell me if
  you disagree.

==> The advantages of this proposal

* 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).

==> Things that are unaffected by this proposal

* New user experience is unaffected. Package installation and
  configuration continues to work out-of-the-box.

* Emacs will still automatically call `package-initialize' in
  startup.el after loading the init-file, unless it was already
  called, or `package-enable-at-startup' is set to nil.

==> Conclusion

If you object to this proposal, please tell me what the concrete
disadvantages to it would be, or explain why the advantages I have
listed are not valid. Otherwise, let's start the process of figuring
out the best implementation.

Best,
Radon Rosborough

[1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html