From: Radon Rosborough <radon.neon@gmail.com>
To: "Clément Pit-Claudel" <cpitclaudel@gmail.com>
Cc: angelo.g0@libero.it, Eli Zaretskii <eliz@gnu.org>,
Stefan Monnier <monnier@iro.umontreal.ca>,
Drew Adams <drew.adams@oracle.com>,
emacs-devel@gnu.org
Subject: Re: Summary and next steps for (package-initialize)
Date: Tue, 22 Aug 2017 22:17:05 -0700 [thread overview]
Message-ID: <CADB4rJFej38NgWK8rd2dRYvqDSk9qzUmVaHiiQQNEBxQEu0rCg@mail.gmail.com> (raw)
In-Reply-To: <befa4ebd-defb-7a44-b6a0-a5abc33ad4b9@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]
> I think I'm not a big fan of your proposal because the only problem I
> see with the status quo is that a call to package-initialize in the
> init file is required at all.
Thank you for this explanation. It is really helpful, as it helps me
see why we have been talking at cross purposes.
> I think I don't see package.el as one out of many, but rather as a
> core component of Emacs. Given this, I'm inclined to be more
> tolerant of exceptions made just for that package.
This helps too. It made me realize that package.el really is core to
Emacs, which I previously failed to see just because I don't really
like package.el as a package manager.
> I'd be fine, for example, with saving package.el's configuration in
> a separate file that gets loaded early.
In light of what I've said above, I would be fine with this too.
Specifically, if we:
* removed all traces of `package--ensure-init-file'
* moved the call to `package-initialize' from after loading the
init-file to before loading the init-file
* loaded an optional second init-file before `package-initialize'
* made absolutely sure that it's trivial to disable package.el
permanently and unconditionally by setting
`package-enable-at-startup' in this second init-file
then I would be perfectly happy and would not bother anyone about this
again. I do want to raise two possible points of concern, which I
personally am fine with but maybe other people aren't:
* doing this would instantly break the configuration of everyone who
customizes package.el or uses it in a nonstandard way -- can anyone
think of a way to maintain some backward compatibility so Drew can
keep his configuration working from Emacs 20 to Emacs 26? ;)
* you will get a bunch of bug reports from people trying and failing
to customize package.el in their normal init-file, I guarantee it --
but this could at least be minimized by inserting big flashy
warnings into the docstrings of all the relevant variables
> That file doesn't need to be a full-fledged ELisp file. It could be
> an alist of relevant keys and values, like a dir-local file.
Bad idea. In particular, this will make it impossible to customize
`package-load-list' so that packages are loaded from package.el by
default, but can be overridden from a local checkout, which is a
pattern I've seen very frequently in the wild.
Besides, if we're going to require it to be static, why not just say
you can only customize package.el via file-local variables in the
primary init-file? (I know, I know, at least you could line-wrap
things. But still.)
~~~
Drew, Stefan, Eli -- would you be comfortable with this alternative
proposal, to add a second init-file as I've outlined above? It would
make package.el "just work" in all cases, without requiring any change
to the user's init-file, as long as users read docstrings before
customizing `package-load-list' etc., and as long as we're prepared to
sacrifice a little backwards compatibility (although maybe we can be
smart about it and make the change pretty painless).
Angelo -- ... sorry :P
I still think that calling package-initialize in the
init-file is "the right thing" from an architecture and
modularity perspective, but having a second init-file may be
a more pragmatic solution.
[-- Attachment #2: Type: text/html, Size: 4347 bytes --]
next prev parent reply other threads:[~2017-08-23 5:17 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-20 2:38 Summary and next steps for (package-initialize) Radon Rosborough
2017-08-20 6:10 ` Drew Adams
2017-08-20 17:20 ` Radon Rosborough
2017-08-20 18:09 ` Drew Adams
2017-08-20 18:39 ` Radon Rosborough
2017-08-21 0:33 ` Drew Adams
2017-08-21 4:08 ` Radon Rosborough
2017-08-20 8:13 ` Stefan Monnier
2017-08-20 17:21 ` Radon Rosborough
2017-08-20 8:15 ` Clément Pit-Claudel
2017-08-20 17:21 ` Radon Rosborough
2017-08-20 14:20 ` Eli Zaretskii
2017-08-20 16:37 ` Alex
2017-08-20 16:44 ` Eli Zaretskii
2017-08-20 16:46 ` Yuri Khan
2017-08-20 16:54 ` Drew Adams
2017-08-20 17:18 ` Colin Baxter
2017-08-22 21:24 ` Alex
2017-08-20 17:22 ` Radon Rosborough
2017-08-20 17:36 ` Eli Zaretskii
2017-08-20 17:54 ` Radon Rosborough
2017-08-21 16:35 ` Eli Zaretskii
2017-08-21 16:43 ` Radon Rosborough
2017-08-21 17:40 ` Eli Zaretskii
2017-08-21 20:33 ` Radon Rosborough
2017-08-22 2:37 ` Eli Zaretskii
2017-08-22 4:52 ` Radon Rosborough
2017-08-22 8:41 ` Clément Pit-Claudel
2017-08-22 16:02 ` Radon Rosborough
2017-08-22 14:33 ` Eli Zaretskii
2017-08-22 18:09 ` Radon Rosborough
2017-08-22 21:01 ` Clément Pit-Claudel
2017-08-21 9:04 ` Stefan Monnier
2017-08-21 14:31 ` Eli Zaretskii
2017-08-21 16:34 ` Radon Rosborough
2017-08-21 17:47 ` Clément Pit-Claudel
2017-08-22 11:37 ` Timur Aydin
2017-08-22 16:58 ` Radon Rosborough
2017-08-22 21:04 ` Clément Pit-Claudel
2017-08-23 5:17 ` Radon Rosborough [this message]
2017-08-23 11:33 ` Angelo Graziosi
2017-08-23 17:16 ` Radon Rosborough
2017-08-23 13:28 ` Drew Adams
2017-08-23 17:31 ` Radon Rosborough
2017-08-23 18:00 ` Drew Adams
2017-08-23 18:32 ` Radon Rosborough
2017-08-23 20:27 ` Drew Adams
2017-08-23 20:59 ` Clément Pit-Claudel
2017-08-23 21:21 ` Drew Adams
2017-08-23 21:44 ` Clément Pit-Claudel
2017-08-23 21:53 ` Drew Adams
2017-08-24 0:44 ` Radon Rosborough
2017-08-24 6:39 ` Drew Adams
2017-08-25 1:03 ` Radon Rosborough
2017-08-24 17:14 ` Eli Zaretskii
[not found] ` <<83fucg99cj.fsf@gnu.org>
2017-08-24 17:44 ` Drew Adams
2017-08-24 18:12 ` Clément Pit-Claudel
2017-08-24 18:29 ` Drew Adams
2017-08-24 21:34 ` Clément Pit-Claudel
2017-08-24 21:40 ` Drew Adams
2017-08-25 1:04 ` Radon Rosborough
2017-08-24 18:14 ` Eli Zaretskii
[not found] ` <<83bmn496js.fsf@gnu.org>
2017-08-24 18:36 ` Drew Adams
2017-08-24 18:57 ` Eli Zaretskii
2017-08-25 1:04 ` Radon Rosborough
2017-08-25 1:04 ` Radon Rosborough
2017-08-23 3:15 ` Stefan Monnier
2017-08-24 16:47 ` Eli Zaretskii
2017-08-24 17:48 ` Stefan Monnier
2017-08-24 18:26 ` Eli Zaretskii
2017-08-25 3:52 ` Stefan Monnier
2017-08-25 3:59 ` Radon Rosborough
2017-08-25 4:39 ` Stefan Monnier
2017-08-25 4:45 ` Radon Rosborough
2017-08-25 4:48 ` Stefan Monnier
2017-08-25 6:47 ` Eli Zaretskii
2017-08-25 11:51 ` Stefan Monnier
2017-08-25 1:04 ` Radon Rosborough
2017-08-25 4:14 ` Stefan Monnier
2017-08-25 4:28 ` Radon Rosborough
2017-08-25 4:47 ` Stefan Monnier
2017-08-25 21:07 ` Stefan Monnier
2017-08-25 21:34 ` Radon Rosborough
2017-08-26 22:29 ` Stefan Monnier
2017-08-26 22:33 ` Radon Rosborough
2017-08-21 16:18 ` Radon Rosborough
2017-08-20 19:09 ` Mark Oteiza
2017-08-23 15:57 ` Nikolay Kudryavtsev
2017-08-23 18:17 ` Radon Rosborough
2017-08-23 19:17 ` Nikolay Kudryavtsev
2017-08-23 19:38 ` Radon Rosborough
2017-08-23 20:09 ` Nikolay Kudryavtsev
2017-08-24 0:13 ` Radon Rosborough
2017-08-24 13:44 ` Nikolay Kudryavtsev
2017-08-25 1:04 ` Radon Rosborough
2017-08-24 17:12 ` Eli Zaretskii
2017-08-23 22:30 ` Nathan Moreau
2017-08-24 0:54 ` Radon Rosborough
2017-08-24 11:13 ` Nathan Moreau
2017-08-24 17:02 ` Eli Zaretskii
2017-08-24 17:52 ` Nikolay Kudryavtsev
2017-08-24 18:31 ` Eli Zaretskii
2017-08-25 13:48 ` Nikolay Kudryavtsev
-- strict thread matches above, loose matches on Subject: below --
2017-08-21 8:24 angelo.g0
2017-08-21 16:22 ` Radon Rosborough
2017-08-21 19:35 ` Angelo Graziosi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADB4rJFej38NgWK8rd2dRYvqDSk9qzUmVaHiiQQNEBxQEu0rCg@mail.gmail.com \
--to=radon.neon@gmail.com \
--cc=angelo.g0@libero.it \
--cc=cpitclaudel@gmail.com \
--cc=drew.adams@oracle.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).