Re: Summary and next steps for (package-initialize)

[Nikolay Kudryavtsev]

Of your two reasons:

A. Yes, it's going to be annoying for two fractions of users, the 
targeted fraction - that is the beginners who didn't set up package.el 
right and old timers during some rare moments of messing with their 
configs. For the later this annoyance would be much rarer than the 
current situation... And I too would have preferred just removing any 
additions, but my proposal seems like an OK compromise.

B. That other package manager should set the variable that suppresses 
the message either within itself or within its recommended configuration 
blob that you paste in your init.

And I don't care about batch mode completely. If you're using batch 
mode, than you know what you're doing.

As for writing package-initialize - well, in case you a)don't use 
package.el and b)don't use any other package manager and c)don't 
suppress the proposed message manually, it's pretty safe to assume that 
you don't have much of init anyway and you're our intended target.

> This whole discussion started  because we don't want package.el doing 
> that.
No, we don't want to write to init, but writing vars to custom is pretty 
normal and used by many packages. It's just that we can't solve 
package-initialize by writing to custom.

> You're going to mucking around with one of the
>   most fundamental parts of the Elisp interpreter (namely, function
>   calls) just for the sake of the package manager.
I'm just proposing to tweak error handling, that's it. While you're 
proposing to add another init file. And we're not talking about the sake 
of a package manager, we're talking about upgrading experience of a very 
limited subset of users(only those new users who haven't yet acquired 
the skill of copy-pasting magic spells into their init). So, while this 
is somewhat ambitious, adding another init just for that is even more so.

--
Best Regards,
Nikolay Kudryavtsev