Neuter package.el

[raxod502]

package.el has annoyed me for the last time by sticking yet another stupid call to package-initialize into my init-file. Henceforth, straight.el shall make package.el completely nonfunctional by overriding its most offensive functions with advice. Out of courtesy I will make this behavior optional.

[wasamasa]

Perhaps your ire would be better placed on emacs-devel. I have argued against this there before, but my arguments fell on deaf ears. If I cared enough, I'd sneak in a patch doing the right thing instead (generating an init file from a template if there is none and we're not in debug mode), but I'm afraid I don't.

[raxod502]

@wasamasa So what was the primary argument against just doing nothing? I mean, if you're just installing packages interactively, then initializing them after Emacs startup will be fine. And if you're configuring them in your init-file, then one would expect you to understand that that will require calling (package-initialize) first.

(I'm pretty sure we're both in agreement here, but I want to understand the situation before I consider making a post on emacs-devel.)

[wasamasa]

The argument was that the lack of (package-initialize) in your init file is the primary stumbling block for people new to Emacs. My argument is that other programs handle this in a lot less annoying ways, such as providing a template config file or creating one if none has been detected.

[raxod502]

Mmm I see. I would be inclined to say that even generating a template init-file is far too much magic, but it would certainly be better than the current situation and would have a much better chance of passing the emacs-devel gauntlet.

I might go ahead and bring this up, if I can persuade myself to subscribe to emacs-devel.

[wasamasa]

The generation part could be as simple as copying a template file to ~/.emacs.d/init.el. I didn't think of more than that.

[raxod502]

@wasamasa I've started a conversation on emacs-devel: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html

[wasamasa]

Wow, thanks! I hope you get more than the tl;dr treatment there though, it would be a shame if discussing the issue from someone else's perspective led to nothing again.

[vyp]

Sorry for the noise, but just also wanted to say thank you for taking the time to write so much about this. I also hope for some more discourse. Because so far I believe no one has given a single reason why a default skeleton init file is not the current behaviour. 🤷‍♀️

[raxod502]

It does look like discourse has dried up, indeed. I'll wait one week and then make a pointed inquiry about whether the lack of any objections to my suggestions means that I should start sending patches.

[wasamasa]

I'd send patches in any case, simply because discussion on debbugs tends to be a lot less emotional.

[vyp]

I don't know if this would affect straight.el in the future since I don't know exactly how you neuter package.el, but I saw in emacs NEWs file for 27.1 they have the following two entries:

+++
** Emacs can now be configured using an early init file.
The file is called 'early-init.el', in 'user-emacs-directory'.  It is
loaded very early in the startup process: before graphical elements
such as the tool bar are initialized, and before the package manager
is initialized.  The primary purpose is to allow customizing how the
package system is initialized given that initialization now happens
before loading the regular init file (see below).

We recommend against putting any customizations in this file that
don't need to be set up before initializing installed add-on packages,
because the early init file is read too early into the startup
process, and some important parts of the Emacs session, such as
'window-system' and other GUI features, are not yet set up, which could
make some customization fail to work.

+++
** Installed packages are now activated *before* loading the init file.
This is part of a change intended to eliminate the behavior of
package.el inserting a call to 'package-initialize' into the init
file, which was previously done when Emacs was started.  As a result
of this change, it is no longer necessary to call 'package-initialize'
in your init file.

However, if your init file changes the values of 'package-load-list'
or 'package-user-dir', or sets 'package-enable-at-startup' to nil then
it won't work right without some adjustment:
- You can move that code to the early init file (see above), so those
  settings apply before Emacs tries to activate the packages.
- You can use the new 'package-quickstart' so activation of packages
  does not need to pay attention to 'package-load-list' or
  'package-user-dir' any more.

The main thing I think is it seems to suggest that setting package-enable-at-startup to nil in init file won't work (needs to be in early-init.el instead). Not sure if that would be an issue for straight?

[raxod502]

https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=24acb31c04b4048b85311d794e600ecd7ce60d3b

You could say I'm aware of the change ;)
Yes, documentation changes are required to straight.el. The problem is not as big anymore since, yes, package.el will get activated automatically, but at least this doesn't involve your init-file getting trampled, which was my motivation for making the change. So I do not think any big code changes are needed. See #420.

[vyp]

Ah I figured maybe this change was due to you but didn't have time to go check history, but thought I should at least leave a comment. :)

So if I'm using development version of emacs I assume I just set package-enable-at-startup to nil in early-init.el file and that's all? (I'm going to try it when I get time.)

Edit: Seems to work

[raxod502]

So if I'm using development version of emacs I assume I just [...]

Sounds about right.