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: Summary and next steps for (package-initialize) Date: Tue, 22 Aug 2017 11:09:41 -0700 Message-ID: References: <83tw12cocz.fsf@gnu.org> <83d17qcfa1.fsf@gnu.org> <83h8x0c206.fsf@gnu.org> <83efs4byzj.fsf@gnu.org> <83378kba5u.fsf@gnu.org> <83ziarad0g.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Trace: blaine.gmane.org 1503425445 24631 195.159.176.226 (22 Aug 2017 18:10:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 22 Aug 2017 18:10:45 +0000 (UTC) Cc: mvoteiza@udel.edu, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 22 20:10:42 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 1dkDdG-0005bg-Ez for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2017 20:10:30 +0200 Original-Received: from localhost ([::1]:42582 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkDdN-0001My-30 for ged-emacs-devel@m.gmane.org; Tue, 22 Aug 2017 14:10:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dkDdD-0001Ly-QU for emacs-devel@gnu.org; Tue, 22 Aug 2017 14:10:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dkDdC-0001ud-EB for emacs-devel@gnu.org; Tue, 22 Aug 2017 14:10:27 -0400 Original-Received: from mail-lf0-x232.google.com ([2a00:1450:4010:c07::232]:33297) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dkDdA-0001nm-HR; Tue, 22 Aug 2017 14:10:24 -0400 Original-Received: by mail-lf0-x232.google.com with SMTP id d17so82712484lfe.0; Tue, 22 Aug 2017 11:10:24 -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=1R1JkieYCOJEYCqguPhAUy27Hpayae1QgIeilDd+9k4=; b=JPtRPYsaKEIhJvMuZBzwIPcESlSUuxc1ufVJvxncntXHQ9okwuz2XJqEkPOQeFVIld 4JD25MGD4AF7C8O1qfu+dosvcLyTvo81JGNUXAHggTy3XhjwTk4ego7QWvHjd37J5D9c RPOEaYu75Fefxay7ZSCJCZjNWyd0nc4Xb/N6yR74TIr6AxjV6thk7Rl8sGd4s2S5+5N3 +yMJ3a6BMRjg7lOG5O1j0iiG1Z8hxhwJPRWZ5fWYG2B+mmDME/uIjYy6sO07jT6ijO9o y0fD0AiwhRJAD8twVsXzg2sO27pPy3kT9x4Lz/nDf1h45wJtZbFB0aNchYC/+dJsshte Odug== 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=1R1JkieYCOJEYCqguPhAUy27Hpayae1QgIeilDd+9k4=; b=n2VaFJN0bMdDyn4vxe4F+n3iEzKtBcjO1cLNYzmcj7VVtfdQ3iuzy//7rOfIWL/vVm V+oj46Gh6OI/7BcmGQHruMikhKSXG1Wbxr4mv2xG75aARMmM9ECTF//cibdpqHA4Cq8H iJDAWQ87rBHI7N8HO24B7b2xTcRH3Jj8d5PXEmb3ikj8AU04kmQrxQXz2qWpXhFbcZS5 OqpvhZaFGbiP78zstRnq+j1WpsSLDYExJ5tA1nNMVMJlo2IbPOR6C1/Vb9GjgjVSuCnP xP13hPxxm5EIONlxkBW2+dSs+pvGZYg+2Yo6Rfx4eDYl+QJ6pA7DfXojv0351uCrlb49 xHeQ== X-Gm-Message-State: AHYfb5hkc1M3xJTQ2ylC+JezWSy9hwPl5gvnm/HbziM/eStjtx6ZsC7k kzGs28igNcinQ+IizIQrqll+Dgfy4eOYbWALQg== X-Received: by 10.25.190.201 with SMTP id o192mr1584lff.246.1503425422696; Tue, 22 Aug 2017 11:10:22 -0700 (PDT) Original-Received: by 10.25.80.3 with HTTP; Tue, 22 Aug 2017 11:09:41 -0700 (PDT) In-Reply-To: <83ziarad0g.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4010:c07::232 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:217696 Archived-At: > I think you forget that file-local variables support 'eval' forms. This is different, since such `eval' forms can be processed just by evaluating them. Whereas the implementation you proposed involved determining the evaluation result of Lisp code without actually evaluating it. > I proposed _an_idea_. You forced me to go into details in an area > where my expertise leaves a lot to be desired, to say the least. I see now that your proposal was more general than I took it to be. I'll try to refrain from overgeneralizing from now on. (I still may point out flaws in particular implementation ideas, though.) > Perhaps we should support a separate .package-exclude file under > ~/.emacs.d, where users would list packages they don't want to load. This is roughly equivalent to having a second init-file, which is indeed a valid solution (although it has the disadvantage that users will inevitably put package.el customizations in their init-files and then get confused when they don't work). > Or maybe it'd be good enough to unload the packages not in the list, > after processing the user init file. I think the resulting performance regressions make this impractical. Not to mention that packages can, in general, run arbitrary Lisp code in their autoloads which cannot be unloaded. > Or maybe people who set package-load-list should also be told to place > the call to package-initialize in their init files, but do it > manually, not automatically by Emacs. This wouldn't solve the problem of package customizations in the init-file not working, which is the primary issue. (But just to be clear, I'm not insisting that you be the one to provide a solution to that problem just because you made the suggestion.) > There could be any number of possible solutions for this issue, > which IMO is minor compared to the larger issue of leaving the user > init file alone, letting the users manage its content as they see > fit. Do you consider a one-time default init-file as violating the principle of "leaving the user init file alone"? That's a perfectly reasonable position; I just haven't heard you say that yet. > And yet we do something similar in file-local variables and > elsewhere, like the .dir-locals.el files. I've already said that this is completely different, since file-local variables can be evaluated directly, whereas anything in the init-file depends on the runtime behavior of the entire rest of the init-file. > So there are solutions along these lines that don't violate the > basic principles, but still solve practical problems in a way that > is acceptable by the user community. Is "not allowing dynamic customization of package-load-list" acceptable by the user community? Honest question. It wouldn't be acceptable by me but then I don't use package.el. > Only because you are trying to solve a larger problem than we need to > solve, and because you are reasoning in absolute terms, rather than in > practical engineering terms. I'm just trying to point out that any ahead-of-time static analysis of the init-file will necessarily fail in some circumstances. If we're OK with that, then fine, but we have to be aware of it. > > I started this thread by proposing a specific, comprehensive solution > > to the problem. Nobody has pointed out any flaws yet. Why is there an > > impasse? > > Because AFAICT no one likes your proposal. Well, nobody (including you) has told me *why* they don't like my proposal. If somebody would explain that, then I would stop bringing it up. Also, Mark Oteiza clearly likes my proposal, so I think "no one" is an exaggeration: > Radon Rosborough writes: > > 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. > > Thanks for pushing the issue. > > > ==> The proposal > > > > The `package--ensure-init-file' logic will be removed > > +1 for reverting. > > I will happily propose and write documentation for various use cases of > package.el, but I will not waste my time as long as the current solution > is in place. In fact, I think Mark is the only person in this whole thread who has made a specific comment directly on my proposal. (I still haven't received replies from you or Stefan requesting a specific explanation of your comments that my proposal is "a non-starter" or will not be "significantly better".) In the meantime, here is my analysis of the options we have: * Require package.el customization to happen in file-local variables. * Scan the init-file for customization of package.el, and accept that this will fail in many cases. * Introduce a second init-file just for package.el. * Don't allow package.el to be customized. * Use a default init-file. * Require users to understand that the package manager must be loaded before packages can be customized. * Leave it as is, where Emacs modifies the init-file programmatically, and accept that this usually does the wrong thing. Let me know if I missed anything.