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: Re: Friendly discussion about (package-initialize) Date: Sun, 6 Aug 2017 21:12:09 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1502079232 16224 195.159.176.226 (7 Aug 2017 04:13:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 7 Aug 2017 04:13:52 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 07 06:13:43 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 1deZQ8-0003TQ-Iz for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2017 06:13:36 +0200 Original-Received: from localhost ([::1]:35278 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deZQE-00081u-S5 for ged-emacs-devel@m.gmane.org; Mon, 07 Aug 2017 00:13:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38928) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1deZPR-00081c-GN for emacs-devel@gnu.org; Mon, 07 Aug 2017 00:12:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1deZPP-0006nE-QS for emacs-devel@gnu.org; Mon, 07 Aug 2017 00:12:53 -0400 Original-Received: from mail-lf0-x22f.google.com ([2a00:1450:4010:c07::22f]:33581) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1deZPP-0006mv-Em for emacs-devel@gnu.org; Mon, 07 Aug 2017 00:12:51 -0400 Original-Received: by mail-lf0-x22f.google.com with SMTP id d17so25242294lfe.0 for ; Sun, 06 Aug 2017 21:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r5QcCp968YYng21GJWxeVDVXiIeFyEVXKAwqmYJcPto=; b=pktlG4hfqy/y/XvG8JMKTpyhBvYUtoCP/K5xWko8xxP8mGtyZyJYIB/14CClrypLEQ rJr3l1sT3YjinA8rWz4OUw44nlr+/AxOUu9XjZZzYxq/VeBsPxQSaNsKuTbPWL2EO3qL WYsOAIcG3UMyA1I6IkThQj14G/gWZNe9So4gcaImS2ppME7ILQMR4YVC4cZRem5UlOX2 z8bhf2+fSQcIgnT46d3/8RwmdtX2uT+33HxCO6vtIKe7yxS15qQEDxMOMkzNM9acDjwR Y0A4Q4/FMV996GzsPl6tpS/ank7zELlFAy00b7fDRgHcjkpOQyZT30dWg28c+SYR3zlW IMUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r5QcCp968YYng21GJWxeVDVXiIeFyEVXKAwqmYJcPto=; b=kyplT/1ErYlYQMCJ8AM+EUEgwcaivGhKtLBoW22xBSe7HuMMGhMI8gGSehJycXfzhO r6CAwC/oMOPycRAN72Mp6phhPQj5iCs03+MFhGZxB8Nq1nvEZg18I4y73vLDQoyvZ90X VfyjCATElRFW4c7pUydtQDXC8cvG0fsqrBP4+jzczAxpjmPAF24Jz+VtX8U6qkDYtk/t aUpzXiVk/CIOKEz2/R6r6sG4l1byTIKWPMymIwe6DlK8tS6LVANEFxOGgjNbVDIH6iIC 1Xv61BxCzEQ4rMlb5eOr4LuHpshEQjVNF9rwXnrO7GGZrMdInM/k1AXq9aBL9IZuLWrW ImiA== X-Gm-Message-State: AHYfb5gst0EXTNllIp3226zVYU9wDuON/0x4T9CXAg6gu9G+oLQ+Km6w kCm525+E6EYrcjF/zwPjhnjgVysUUsQnWIQ= X-Received: by 10.25.21.153 with SMTP id 25mr2878206lfv.109.1502079170052; Sun, 06 Aug 2017 21:12:50 -0700 (PDT) Original-Received: by 10.46.64.86 with HTTP; Sun, 6 Aug 2017 21:12:09 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::22f 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:217353 Archived-At: > > The problem is that even if I don't use package.el, there may be > > some stuff left in ~/.emacs.d/elpa from previous times. > > Then don't do that: I'm actually not sure what "that" is referring to here. Sorry if it is obvious. > we want to make it as straightforward as possible for users to > install&use packages from GNU ELPA, so automatic activation of those > packages that were installed is a prerequisite. Agreed, but it doesn't have to be done in this way. We could accomplish the same thing simply by providing a template init-file, without any of the problems I've mentioned. Is there any particular reason why providing a template init-file would be a worse solution than modifying the init-file on the fly? If so, could you explain to me what it is? Let me reiterate: providing a template configuration file is an *extremely common pattern*, and it's even common for the default behavior of a program (when run with no configuration file) to be generally considered unacceptable. The principle of least surprise suggests that Emacs should use the same system as every other piece of software with this kind of problem uses. > Inevitably there will be situations where this design goal will > clash with the end-user who wants to use something else and will > want to explicitly "disable" package.el. I'm fine with disabling package.el being an explicit step. Not with it being an ongoing battle (where package.el strikes back every time I accidentally use one of its functions without the proper advices defined). I would be totally satisfied with there being package.el code in the template init-file and no mention of alternative package managers, as long as it ends with the template init-file (i.e. it's a one-time thing). > Do you mean that it would be worse, or that it would be better but > still not good enough? Better but still not good enough. I would consider modifying the init-file automatically at startup as "atrocious" and doing it at other times "undesirable but acceptable if it's really the only solution". > Based on your earlier message, I'm pretty sure I will not come up > with a solution which you really like, so I'm only aiming to get > "better" rather than "good enough". That's OK. I certainly don't believe it's the responsibility of the Emacs community to make me happy; sorry if I gave that implication. > > Would you consider it an acceptable solution to pop up a window or > > display a message telling the user that they should put > > `package-initialize' in their init-file, provided that we didn't > > have it get called during init? > No, Yeah, a popup window would be very annoying. It was just an offhand suggestion. But consider that package.el doesn't currently display any useful message in the echo area after it's finished (just whatever byte-compilation message happened to be last). I don't think it would be a degredation to user experience to have it say Finished installing 2 packages and then if package-initialize wasn't called during init, Finished installing 2 packages, but please run M-x package-ensure-init-file to finalize installation or something like that. Perhaps a *Warning* would be appropriate? As long as the message conveyed a way to find out more details, and a quick fix (I'm fine with advising to use a function that modifies the init-file, as long as that's an intentional action). I'm partially playing devil's advocate here; I really think the template init-file is the way to go. But even if we do use the template init-file, some better messaging would still be nice, I think. > (all of whom likely already know several different ways to work > around the current annoyance) Based on the Reddit thread I linked, most people who encounter this problem don't know how to fix it. The ones who do spent an hour or two figuring out how to do so because there's no documentation. > But if the call is only inserted during package-install it means > that you'd need both: > - use package-install > - in a session where your init failed to call package-initialize > for the problem to show up. This combination seems a lot less likely > than the current one. This happened to me repeatedly when I was testing package managers, since I obviously wanted to test installing packages in an environment where they weren't already activated by my primary package manager. I do agree that this situation is uncommon; it just strikes me that the mechanism currently in use is rather fragile if it "breaks" in such a situation. > Another thing we could consider is to drop the automatic call to > package-initialize in lisp/startup.el (again, based on the idea that > this has now been made unnecessary by package--ensure-init-file). I am strongly in support of this unless it means that we will be more reluctant to eventually remove `package--ensure-init-file'. Almost all of the tangible problems I mentioned in my original email stem from package.el modifying the init-file on the fly; arguing for the elimination of this behavior is therefore my highest priority. > So it seems like you're thinking of another kind of "plain Emacs but > not in `emacs -Q`". No, I was thinking of the same situation. I know I have been bitten by this before, but thinking back on it I can't say that any of my use cases there are actually common in any way. Let's pretend I didn't make that point; I don't think it is useful. > >> I'd be very interested to work with maintainers of other package > >> managers to see how we could make them better interoperate (e.g. > >> make it possible to install with one tool, but activate&config with > >> another). > > Sounds like a great idea. However, do note that this will only be > > useful for package managers that use the package.el format (e.g. > > Quelpa, Cask, Pallet) and not for others (e.g. el-get, Borg, > > straight.el). > > Part of "make them interoperate" may involve changing the formats > accepted&|used by the various tools, indeed (on-disk, on-the-server, > ...). Note that source-based package managers such as Borg and straight.el are fundamentally incompatible with the package.el format (or, depending on your perspective, the package.el format is fundamentally incompatible with source-based package managers such as Borg and straight.el). el-get might benefit from this improved interoperability, though it is an interesting case as it's the only package manager I know of that uses both package.el and non-package.el formats for packages. Best, Radon