Regarding (package-initialize)

[wasamasa]

See also emacs-devel and my proposed solution. @Malabarba suggested changes done to package.el to solve the problem of newbies tripping up over needing (package-initialize) in their Emacs configuration to which the solution of automatically inserting such a line came up. While the remaining thread devolved into discussion of technical merits of this and other solutions, I did wonder whether the original problem didn't just happen because at least one popular package archive didn't mention this complication at all.

And indeed, MELPA does mention (package-initialize), but Marmalade doesn't (same for GNU ELPA). I therefore propose adding such a hint at the end of its installation instructions (something along the lines of "If you wish to customize Marmalade packages in your init file (.emacs or init.el), you'll most certainly want to insert (package-initialize) before these to instruct Emacs to load the exposed configuration points. Alternatively, write a function doing the customization and add it to after-init-hook with (add-hook 'my-customization-setup 'after-init-hook).") and see what effect it has.

[Malabarba]

Hi Vasilij,
I agree it would be nice for Gelpa and Marmalade to say that on the
frontpage. Even if we have a solution for the problem in 25.1, it's still
going to plague users of older Emacs versions.

I'll look into how to add that to Gelpa.

Best,

2015-05-03 7:58 GMT+01:00 Vasilij Schneidermann [email protected]:

See also emacs-devel
http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01016.html and my
proposed solution
http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00639.html.
@Malabarba https://github.com/Malabarba suggested changes done to
package.el to solve the problem of newbies tripping up over needing
(package-initialize) in their Emacs configuration to which the solution
of automatically inserting such a line came up. While the remaining thread
devolved into discussion of technical merits of this and other solutions, I
did wonder whether the original problem didn't just happen because at least
one popular package archive didn't mention this complication at all.

And indeed, MELPA does mention (package-initialize), but Marmalade
doesn't (same for GNU ELPA). I therefore propose adding such a hint at the
end of its installation instructions (something along the lines of "If you
wish to customize Marmalade packages in your init file (.emacs or init.el),
you'll most certainly want to insert (package-initialize) before these to
instruct Emacs to load the exposed configuration points. Alternatively,
write a function doing the customization and add it to after-init-hook
with (add-hook 'my-customization-setup 'after-init-hook).") and see what
effect it has.

—
Reply to this email directly or view it on GitHub
#102.

[nicferrier]

I quite disagree with adding information about package-initialize.

It's only people perpetuating the advice that makes it necessary.

[email protected] writes:

Hi Vasilij,
I agree it would be nice for Gelpa and Marmalade to say that on the
frontpage. Even if we have a solution for the problem in 25.1, it's still
going to plague users of older Emacs versions.

I'll look into how to add that to Gelpa.

Best,

2015-05-03 7:58 GMT+01:00 Vasilij Schneidermann [email protected]:

See also emacs-devel
http://lists.gnu.org/archive/html/emacs-devel/2015-03/msg01016.html and my
proposed solution
http://lists.gnu.org/archive/html/emacs-devel/2015-04/msg00639.html.
@Malabarba https://github.com/Malabarba suggested changes done to
package.el to solve the problem of newbies tripping up over needing
(package-initialize) in their Emacs configuration to which the solution
of automatically inserting such a line came up. While the remaining thread
devolved into discussion of technical merits of this and other solutions, I
did wonder whether the original problem didn't just happen because at least
one popular package archive didn't mention this complication at all.

And indeed, MELPA does mention (package-initialize), but Marmalade
doesn't (same for GNU ELPA). I therefore propose adding such a hint at the
end of its installation instructions (something along the lines of "If you
wish to customize Marmalade packages in your init file (.emacs or init.el),
you'll most certainly want to insert (package-initialize) before these to
instruct Emacs to load the exposed configuration points. Alternatively,
write a function doing the customization and add it to after-init-hook
with (add-hook 'my-customization-setup 'after-init-hook).") and see what
effect it has.

—
Reply to this email directly or view it on GitHub
#102.

---

Reply to this email directly or view it on GitHub:
#102 (comment)

[wasamasa]

@nicferrier Well, how about at least noting the alternative (using after-init-hook and eval-after-load judiciously)?

Also, note that @Malabarba's solution consists of inserting (package-initialize) into the init file upon usage of package.el unless it's already present. If you aren't happy with that, I encourage you to participate in the linked discussion.

[Malabarba]

FWIW, Gelpa now says "Since you'll probably want to use your installed packages, it's also recommended that you add (package-initialize) somewhere in your ~/.emacs file.".

It's only people perpetuating the advice that makes it necessary.

What advice are you referring to? Adding configuration snippets to your init file? Do we have a viable alternative?

[wasamasa]

@Malabarba The viable alternative to adding (package-initialize) at the top of the init file is using after-init-hook for that purpose (which requires more work, but results in a cleaner Emacs configuration). See my Emacs configuration for a non-trivial example of this strategy.

I'm not terribly happy with the new advice at GNU ELPA since it's neither precise (add it where and for what purpose exactly?) nor links to the respective manual section.

[Malabarba]

The viable alternative to adding (package-initialize) at the top of the init file is using after-init-hook for that purpose (which requires more work, but results in a cleaner Emacs configuration).

I don't see why adding all your package configurations (which might be almost your entire init file) to a hook is any cleaner than calling (package-initialize). In fact, it's a little bit worse because for some packages custom-set-variables won't work properly if packages haven't been initialized yet.

I'm not terribly happy with the new advice at GNU ELPA since it's neither precise nor links to the respective manual section.

I'll try to add the link as well.

(add it where and for what purpose exactly?)

Frontpage advice should be short and to the point. In any case, linking to the manual will help answer the purpose.

[wasamasa]

It is only the entry points of packages you'll want to have enabled, for my config that makes 23 lines of code vs. the remaining over 2000 lines of code (which use `with-eval-after-load' and hooks heavily). As for the custom set forms, I've only needed to analyze two or three of them. Other users might instead use customize directly if it's a few of them.

[Malabarba]

It is only the entry points of packages you'll want to have enabled, for my config that makes 23 lines of code

That still doesn't make it any better/cleaner than package-initialize. ;-)

[nicferrier]

I have participated in the discussion.

I strongly resisted @Malabarba's suggestion. It's a pointless change to semantics. Adding a standard after package init file (.emacs.d/init-post.el, say) is my suggestion. Nobody wanted that though.

[Malabarba]

Well, one of the two "finalist" options in that discussion was kind of that but the other way around. It would add a pre-package-init file, and then the usual init.el becomes your after package init file.

[nicferrier]

Yeah. Great. Thus breaking everyone who did it properly but not everyone who couldn't be bothered.

[Malabarba]

While I don't know exactly how many people's config will break, I wonder what makes you say everyone.

[wasamasa]

Could you please let the offtopic alone and concentrate on the original issue?

@nicferrier Do you agree going for either option as enhancement to the current installation instructions?