From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sebastian Wiesner Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Tue, 31 Mar 2015 16:51:38 +0200 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1427813540 9625 80.91.229.3 (31 Mar 2015 14:52:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 31 Mar 2015 14:52:20 +0000 (UTC) Cc: emacs-devel To: bruce.connor.am@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 31 16:52:11 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YcxWU-0000bZ-C0 for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 16:52:10 +0200 Original-Received: from localhost ([::1]:39095 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcxWT-0004q3-Tx for ged-emacs-devel@m.gmane.org; Tue, 31 Mar 2015 10:52:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59253) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcxW5-0004TK-GU for emacs-devel@gnu.org; Tue, 31 Mar 2015 10:51:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YcxVz-0003En-RS for emacs-devel@gnu.org; Tue, 31 Mar 2015 10:51:45 -0400 Original-Received: from mail-wg0-f47.google.com ([74.125.82.47]:35876) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YcxVz-0003EQ-Ln for emacs-devel@gnu.org; Tue, 31 Mar 2015 10:51:39 -0400 Original-Received: by wgra20 with SMTP id a20so22082969wgr.3 for ; Tue, 31 Mar 2015 07:51:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=1gQNEiCiESJuonO0AX5u/yjdfEJ9CTWIffEPQBMMOQ4=; b=IO59MRj30pruVVHRN4IE6TOVL6QTULhcFiZNu8bj65Y7lRVeiMvlhDMaTBacSgZz8d 9iX5PMoPbFdkBl+BkRpq3fiA9JiladamYtAQvJwrgGrfzVEtlTOgrS0aCJa/jHseQgAW nYJ+F/0fbcTsL74IJp/W3WXmfd1XFxwmoNKLkvCDs3FgltV9jl4G8cP5jAmroHG3G1FD NKlrGFF31wb/fRZc7KTh37G0tZAAX0ckKo4xb2C/5zpXyjZA96pk2I08ykj4YSTLt8MR ZxJxQbEIkD3s5rAUQMVWlq8UXbDR+3ENYnKlJfiQYao59TZM0mBMJZBRpqP0X6L9cGca t2LA== X-Gm-Message-State: ALoCoQk7/9Z5hHZQ+yaLAHn1y77UleSjoe/QosqKXmQOkJTw8d/moETzVnfZrH0sQ2UF+DTFrXjt X-Received: by 10.180.187.43 with SMTP id fp11mr6169762wic.8.1427813498376; Tue, 31 Mar 2015 07:51:38 -0700 (PDT) Original-Received: by 10.27.14.81 with HTTP; Tue, 31 Mar 2015 07:51:38 -0700 (PDT) X-Originating-IP: [213.95.17.180] In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 74.125.82.47 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:184643 Archived-At: 2015-03-30 21:01 GMT+02:00 Artur Malabarba : > On the "Customizable modes..." thread I suggested we run > (package-initialize) sooner than the way it's currently done. Right > now, it's called after loading the init file. Which means any user who > tries to customize an installed package by pasting some code into his > init file will be confronted with errors. > This happens A LOT. > > Stefan kindly explains why it can't just be done before loading the init = file: >> [...] the user may need/want to run some Elisp >> code of his own choosing *before* package-initialize is called. >> E.g. [...] set package-load-list and package-directory-list > > But I'm asking that we try a little harder to find a better solution. > This package.el-induced "cannot find load file" error is the most > predominant issue I see people run into in the wild. Some people file > issues for this stuff on github (and waste developer time), others go > to the relevant forums, and others (I can only imagine) probably just > give up on configuring packages (or give up Emacs!) entirely. > > So I hope we can try to converge on an actual solution instead of just > resigning to something that harms the majority of the users. I propose > here a couple of suggestions which still preserve the use-case outline > by Stefan, and I'm perfectly open to other ideas. > Even if we can't find an ideal solution, try to keep in mind how > absurdly unideal the current situation is. > > Option 1) Check if the file `~/.emacs,d/.package-delay-init' exists. > If it does, just do it the way we currently do. If it doesn't exist, > do package-initialize first and then load the init-file. This > `.package-delay-init' file is not loaded, Emacs would only check if it > exists. > > Option 2) Instead of us manually telling users to add > `(package-initialize)' to their init-files, we have Emacs do that > automatically. Similar to how `custom.el' adds a call to > `custom-set-variables' the first time you save a variable; package.el > could add a call to `package-initialize' the first time you install a > package. This would be a one-time-thing (and would take some > intelligent coding to prevent annoyiances). > > Thank you all, > Artur > I probably underestimate the complexity of this issue, so please forgive if I say anything stupid, but=E2=80=A6 isn't this much too complicated? For most defcustom's it doesn't actually matter whether they are set before or after the corresponding feature is loaded, does it? So there's only a very specific class of defcustom's which is affected at all: Namely, modes enabled through customize. For these specific defcustom's the corresponding feature must be loaded immediately anyway, since we must have the mode function available to actually enable the mode, right? So we could just require that a mode that is supposed to be enabled through customize also has a ':require' keyword for the corresponding feature. And for :require features the whole problem looks pretty simple to me: Try to load the feature on 'set-custom-variables'. If it fails remember the corresponding form somewhere (i.e. 'custom-delayed-vars' or whatever), and just try again after 'package-initialize'. If it still fails, report an error. That sounds like a simple and straight-forward approach that's not too invasive or too magic. Would that not work?