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: Summary and next steps for (package-initialize) Date: Sat, 19 Aug 2017 19:38:05 -0700 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1503196787 19887 195.159.176.226 (20 Aug 2017 02:39:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 20 Aug 2017 02:39:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 20 04:39:41 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 1djG9G-0004Tb-2m for ged-emacs-devel@m.gmane.org; Sun, 20 Aug 2017 04:39:34 +0200 Original-Received: from localhost ([::1]:37824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djG9M-0000EG-PO for ged-emacs-devel@m.gmane.org; Sat, 19 Aug 2017 22:39:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1djG8Y-0000D9-BS for emacs-devel@gnu.org; Sat, 19 Aug 2017 22:38:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1djG8X-0000fT-5s for emacs-devel@gnu.org; Sat, 19 Aug 2017 22:38:50 -0400 Original-Received: from mail-lf0-x236.google.com ([2a00:1450:4010:c07::236]:33768) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1djG8W-0000ea-TZ for emacs-devel@gnu.org; Sat, 19 Aug 2017 22:38:49 -0400 Original-Received: by mail-lf0-x236.google.com with SMTP id d17so55196304lfe.0 for ; Sat, 19 Aug 2017 19:38:47 -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; bh=Mdpe8kj8sEYYBc19SgDus2IHp47Ou85LDjsTDCRpAGM=; b=Ryh8BzbqEZqMzua3LxUCVLLnu9ldaJVe28DKKasznAv9x7FiF7krSxlZm0eRUT0GaR IwpXMVBuf7dfgkLvCyR6XOOxLLk3aB3CaMOLrmuUHyjbu6hZ69kIkAwy9NwW6VxkAxep y2Dz3/0gM3KRNQv7EshrE0Gr4PESoq2cS7Bla4kNoVTLLxOIFBBeJ6D+0OxUpHme/Kqj 9PE3itJyUgrw6YRiIa1VbuvIIO2rHwviMKyJhHeaLO/CsJqqMbGCfWtipXZdpOEzjPj9 gCZUGgkmaKftPvHo1iXSV5BoQYvgWcIrMcEsfQ5kU2VNCdCzLCSpWmiobjZVRmN55P9V KH+g== 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; bh=Mdpe8kj8sEYYBc19SgDus2IHp47Ou85LDjsTDCRpAGM=; b=Fkh2i40XNHuB+tom53WcFvLr0JB/wXFN5scRX7+TQ6jZDuroeqMx2Pz3CKQtQnoCtG QBLhXKm/WX99k01BkIM9hUC3UnJoRIPor0Jw0QmxvxNLG6GSImueUO6fYyOUsvl38Xhs OMRvV8Kklgofq5r0m+w68Ijcc6M0RN8EeVt3o+D1l5KkvvatudMCD/+Qgk6q7RU5mDub 2Htokyj21+1sXdiG7Q5cr4uyJdxlz/S/WXr9GO15nWx0pwDxUd5I6VUQW43hHvtyBz9P o5qqfWj8bXKtlJeA8mun6v7wfDylRej3HbDPJ/fdPT+I1C/314pY7h9wxQ5dElF8aw2E grmg== X-Gm-Message-State: AHYfb5iq1p3RG+XETSfGrWdsNSeM4//QcL7uV56XXeZHDnNQfEi8lWJM doto3f88jAuM78OPLB27CxcDEGJXPG1fzGw= X-Received: by 10.25.59.213 with SMTP id d82mr4063214lfl.37.1503196725938; Sat, 19 Aug 2017 19:38:45 -0700 (PDT) Original-Received: by 10.25.80.3 with HTTP; Sat, 19 Aug 2017 19:38:05 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::236 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:217625 Archived-At: SUBJECT: Summary and next steps for (package-initialize) FROM: radon.neon@gmail.com TO: emacs-devel@gnu.org Hi all, Last week I posted an inquiry [1] about package.el's auto-insertion of code into the init-file. Six people weighed in, but no definitive conclusion was reached. I would like to propose concrete next steps, summarizing relevant parts of the discussion in the process. ==> The proposal The `package--ensure-init-file' logic will be removed, and package.el will not ever directly modify the user's init-file. However, if Emacs is started with no init-file, then a default one will be generated and loaded (except in 'emacs -Q'). This template init-file would include a call to (package-initialize) and some comments explaining that package configuration must be put after (package-initialize). ==> The disadvantages of this proposal * If somebody (1) has an existing init-file, (2) uses package.el to install a package, (3) adds configuration code directly to their init-file, (4) fails to read the documentation about the need for `package-initialize', and (5) has not used package.el in the last year or two, then their package configurations will not work. I argue that this specific use case is virtually nonexistent. In particular, the vast majority of people already have (package-initialize) in their init-file due to the previous behavior of package.el, and new users will get to use the template init-file. Thus, I do not think this is a real disadvantage. Please tell me if you disagree. * Emacs is creating a whole file without being asked. I argue that the current behavior is worse in this regard than the proposed behavior. The current behavior is that user-created files are edited automatically by Emacs. The proposed behavior is that nonexistent files are created automatically by Emacs. It seems clear to me that automatic file creation is much safer than automatic file editing. Thus, I do not think this is a real disadvantage. Please tell me if you disagree. ==> The advantages of this proposal * Emacs does not automatically modify the user's init-file without asking. This eliminates a wide range of unfortunate and annoying side-effects, as you can imagine. Here are two: - People who don't want to use package.el don't get irrelevant and damaging (because of duplicate loading) code stuck in their config. - People who use package.el but call (package-initialize) in some file other than init.el will not get a superfluous call inserted (which might well break their config) if there happens to be an error during init. * In future, if we wish to improve the "out-of-the-box" user experience, we can do so without needing to break backwards compatibility, by simply modifying the template init-file. * It's consistent with standard best practices. All other programs which have a similar problem to package.el solve it by providing a template config file. The reason that all these other programs avoid modifying their config files is the same reason that package.el should avoid modifying the init-file as well. * It will never accidentally place (package-initialize) in the wrong place, which happens frequently with the current system and defeats the entire purpose of an aggressive hack to make things "just work". In fact, the current system *always* places (package-initialize) in the wrong place if the user happened to customize anything like `package-archives' in their init-file (which is extremely common, and I'd go so far as to say that *not* doing this is the uncommon case). ==> Things that are unaffected by this proposal * New user experience is unaffected. Package installation and configuration continues to work out-of-the-box. * Emacs will still automatically call `package-initialize' in startup.el after loading the init-file, unless it was already called, or `package-enable-at-startup' is set to nil. ==> Conclusion If you object to this proposal, please tell me what the concrete disadvantages to it would be, or explain why the advantages I have listed are not valid. Otherwise, let's start the process of figuring out the best implementation. Best, Radon Rosborough [1]: https://lists.gnu.org/archive/html/emacs-devel/2017-08/msg00154.html