From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Proposals for fixing package-initialize Date: Sun, 3 Sep 2017 22:31:57 -0700 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1504503178 13595 195.159.176.226 (4 Sep 2017 05:32:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Sep 2017 05:32:58 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 04 07:32:51 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dok0A-00032X-5h for ged-emacs-devel@m.gmane.org; Mon, 04 Sep 2017 07:32:50 +0200 Original-Received: from localhost ([::1]:33119 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dok0F-0002nm-Gd for ged-emacs-devel@m.gmane.org; Mon, 04 Sep 2017 01:32:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45197) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dok03-0002mj-CK for emacs-devel@gnu.org; Mon, 04 Sep 2017 01:32:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dok01-0005aG-OW for emacs-devel@gnu.org; Mon, 04 Sep 2017 01:32:43 -0400 Original-Received: from mail-lf0-x22e.google.com ([2a00:1450:4010:c07::22e]:33838) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dok01-0005Z3-Cp for emacs-devel@gnu.org; Mon, 04 Sep 2017 01:32:41 -0400 Original-Received: by mail-lf0-x22e.google.com with SMTP id d17so16219828lfe.1 for ; Sun, 03 Sep 2017 22:32:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=1B3ySgfjemCYgThBQP0fPNNzXplP/1yb+KMsAZ1USK0=; b=lbLlFTTwAkJYQK0lZhbOp1wVMUmNQ55Jfs/xllmYJILG5sO5+DpW+3IY1LG2dvLlj1 31uHz0dn9CazPxwJH5o0N1nna6FBwUZU9TvYA7QmZIdb/4v2wGwGU4nNSwGJ+F5AR+5K owwUzHhvO9qo760sVJ6BQLMLBsstOQvZLF6xO2M2zW/KQ/1KSkRCi/s5K1Ba70caCVCX iuZZWXEj5yk51elgJhfXtXvBSHV6QFJcekv0N7TjdQTyqg6ZjstsezRGyZlw2FofVXdH d4gkx+E/d519TKEds1qmw0Wd3OWsCOsO99Evs8LbBxrZkKuWXXPLqf0v8XvhSalkAS3U IaDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=1B3ySgfjemCYgThBQP0fPNNzXplP/1yb+KMsAZ1USK0=; b=tPAaSy8GDwd5pE2iEb70UfhmKmq1w17KD7QghumkrkEgB3T+te7m5JmXJAPrtcUOJ9 0PK2rAaU7wDTnTttiUdt85wUB/NX5oDW0KsO+BH9AjWb25G32Pi4fkYCy5+FJeWCTsvQ zfmf1+3aYAyIHUeeQbnk9HXhlmVcZM+3WWcpO2yoAoh+yr4m+Zj9HBrrc456nYTjlbGe C5ESgzLI3g5NsONyqGpXvd4qlh0J8VBrrZk4lJOTHQj3jzZQky/o8MCVEhlVNS7U2RJr vCyWtC38Cm83irIrlniQUA+4jJ+yGeW5RMuWj543jfWzXh3ez6lt+RXmIwuz4hTkxOHO jlsQ== X-Gm-Message-State: AHPjjUi1HrWHzroUh1RWERSv7iqsFMqBgBlsALRMZ3+AAA69MPHzDzft 2MnRC6qZKzIfpEOdouMjk56RqFJEQ/cYBqs= X-Google-Smtp-Source: ADKCNb41Tz1pG+BYUN/qkNg1Ub592BBd3h1NHu6ce8R1Bu1vOLkWqo53bw4/vXpPx9OMILBzDxX5ECUKCEyMLp3uqPQ= X-Received: by 10.46.0.14 with SMTP id 14mr3562016lja.191.1504503158363; Sun, 03 Sep 2017 22:32:38 -0700 (PDT) Original-Received: by 10.25.84.221 with HTTP; Sun, 3 Sep 2017 22:31:57 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:217921 Archived-At: Hello all, You may have seen slightly over 150 emails fly by in the last few weeks talking about package-initialize. Hilariously, we still haven't managed to reach a conclusion. This email is an attempt to present all the proposals that have been discussed, in an even-handed way, so that we can make a decision without everyone needing to have read the aforementioned 150 emails. I will *not* be providing any context on the issue; see [1] for that, but note that the discussion branched out so much that everyone's positions are now completely different :P =3D=3D> Proposal A: Leave it alone Summary: - call package-initialize in startup.el after loading the init-file - when package-initialize is called, also insert a call to it into the init-file, if one was not found there - this is the current behavior Advantages: - requires no work - people are used to the current behavior - backwards compatible Disadvantages: - modifying the user's init-file is ugly - doing it automatically is annoying and possibly dangerous - if the user has customized package.el, then Emacs will put package-initialize in the wrong place - this type of behavior is not common practice =3D=3D> Proposal B: Add a second init-file Summary: - add a second init-file, ~/.emacs.d/early-init.el - this file is sourced earlier than init.el, during startup.el - move the call to package-initialize in startup.el from its current location to between early-init.el and startup.el - don't have package.el modify the init-file ever Advantages: - does not require modifying the user's init-file - package.el still works out of the box - the only people affected by the change are the ones who have customized package.el - foolproof, never does the wrong thing (except for advanced existing configs that customize package.el) - people can also use early-init.el to disable things like the tool bar before they are loaded in the first place: two birds with one stone - the only people who need to know about early-init.el are advanced users who want to customize package.el - Customize works both for customizing package.el and also for customizing packages - does not require package-initialize to be put in the user's init-file, not even manually - makes it easy to disable package.el permanently Disadvantages: - adds another init-file, which is additional complexity - we must add a mechanism to Customize that allows to specify the file into which a particular variable should be saved, so package.el can still be customized =3D=3D> Proposal B': Add an early-init special form Summary: - same as above, but instead of a separate file, allow init.el to start with a special (with-early-config ...) form - if with-early-config form is found in init-file, load it when early-init.el would be loaded Advantages: - we still only have one init-file Disadvantages: - the startup sequence is a little weird - it's not clear how this would work with Customize =3D=3D> Proposal C: Add a template init-file Summary: - if Emacs is started without an init-file, generate one from a template - the template init-file has a call to package-initialize in it, and some comments explaining where to put package and package.el configuration - the template init-file is not generated in 'emacs -Q' mode - get rid of package.el modifying the init-file Advantages: - does not require modifying the user's init-file - package.el still works out of the box for new users - we could use the template init-file for encouraging users towards better defaults without breaking backwards compatibility Disadvantages: - having Emacs automatically create files is not ideal - if we decide against using the template init-file for better defaults, then it's kind of awkward to just use it for package.el - doesn't work for users with existing init-files - still reqiures a call to package-initialize in the user's init-file =3D=3D> Proposal D: Hook into error handlers Summary: - call package-initialize whenever a void-function or require error is encountered - get rid of package.el modifying the init-file - possibly get rid of call to package-initialize in startup.el? Advantages: - doesn't require modifying the user's init-file - probably package.el still works out of the box Disadvantages: - implications (performance, correctness, implementation details) are completely unexplored - not very elegant - business logic from the package manager is intermixed with a fundamental, generic part of the Elisp interpreter - hard to tell when package-initialize gets called, so best practice would probably still be to have package-initialize in the init-file - the fact that a core Lisp error causes lots of magic to happen will make debugging more "fun" =3D=3D> Proposal E: Call package-initialize multiple times Summary: - add a second call to package-initialize before init.el is loaded - if package-initialize is called again, and package-load-list or other variables have been customized since the last time it was called, unload any packages that were previously loaded that now should not be loaded Advantages: - does not require modifying the user's init-file - backwards compatible, at least if it works Disadvantages: - impossible to disable package.el without introducing a magic dotfile (~/.emacs.d/.nopackage) or similar - impossible to unload packages correctly, in general, so this approach would be buggy in many edge cases - severe performance regressions if many packages are disabled using package-load-list - "As I said, there's no doubt that do+undo is a poor way to do nothing." "Again, here we're back to the obvious observation that do+undo is a poor and complicated way to do nothing." "Can't disagree that "do+undo" is a poor way to do nothing." -- Stefan - requires extra work to make multiple calls to package-initialize faster, not to mention figuring out how unloading is supposed to work, or if that's even possible in principle =3D=3D> Proposal F: Use more declarative configuration Summary: - make it so that packages can be configured in a way that causes package-initialize to be called automatically Advantages: - would solve all the problems Disadvantages: - nobody has any idea how to do this - and it would probably take several years anyway =3D=3D> Proposal G: Parse the init-file Summary: - call package-initialize in startup.el before loading init.el - parse the init-file in order to find out the values of package-load-list, etc. before running package-initialize Advantages: - in the cases that it works, it would allow package.el to work out of the box without the need for package-initialize in the user's init-file - Emacs would not need to modify the user's init-file Disadvantages: - would require solving the halting problem to work in general - is a horrifying hack =3D=3D> Proposal H: Make the user do it manually Summary: - make it so that package.el doesn't modify the init-file, but don't change anything else - this is how it worked before the first "solution" to this problem was implemented Advantages: - Emacs does not modify the user's init-file Disadvantages: - package.el does not work out of the box, since package customizations will fail when put into the init-file - consequently we get lots of superfluous bug reports =3D=3D> My position I think that the above advantages and disadvantages speak for themselves, but to be clear, I think Proposal B is the best. It has basically no practical disadvantages, solves every problem that is tangled up in this issue with zero migration necessary except for very advanced users, is trivial to implement, and simultaneously solves a large class of other problems related to disabling things that are enabled early during startup. Every other proposal has significant practical disadvantages. =3D=3D> Postscript I'd like to say thank you to Eli for pushing the question of whether it would be practical to call package-initialize only in startup.el, Timur for questioning why a second init-file would be so bad, and Cl=C3=A9ment for explaining to me what was wrong with my original proposal. Their arguments resulted in the discussion of what I now think is a better proposal than my original one. And yes, I really did review all 150 of those emails to gather information for this summary :o Best regards, Radon Rosborough [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html