From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Mon, 20 Apr 2015 16:31:29 +0200 Message-ID: <878udmj2gu.fsf@taylan.uni.cx> References: <87383xk4ia.fsf@taylan.uni.cx> <87d22zi69k.fsf@taylan.uni.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429540340 29487 80.91.229.3 (20 Apr 2015 14:32:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 14:32:20 +0000 (UTC) Cc: Philipp Stephani , Artur Malabarba , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 16:32:16 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 1YkCkC-00042T-0s for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 16:32:16 +0200 Original-Received: from localhost ([::1]:53926 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCkB-000050-DS for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 10:32:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33212) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCjX-0007mT-GT for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:31:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkCjW-0007DX-79 for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:31:35 -0400 Original-Received: from mail-wg0-x231.google.com ([2a00:1450:400c:c00::231]:33907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkCjV-0007Cc-S8 for emacs-devel@gnu.org; Mon, 20 Apr 2015 10:31:34 -0400 Original-Received: by wgso17 with SMTP id o17so181527004wgs.1 for ; Mon, 20 Apr 2015 07:31:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=Cuaaenj/yyPca1vmkgMpmhg3NA/v3K9htU/fcdCJo4Y=; b=oYaSiiDQuKYQNhiav43UWdsNlFaFGqEHlMEbzl3REGBJnQzUvlt5UOIag7wNxZVr87 R8BCbXqWXCzqNnSXQ4cWeMlropZ9j9hVhUVbF+NJiupqqb5bAP0dF/4hZCF4InWKtg90 O4IBsqddukX0Yq+jDZOGT1CjNXX3T/j0LydjjmBSsWyxatUJxqPKJkzn5PoMHvqDZqsO 5bNcHp3meVisQsEkLZS1ZMCQubf1pB0o3hYNWfyUHKdRZJyhBZ4YlziFSNHcau6UpGpx 4rkpLu7+kpj0npMp3nbuVrXw4FCRu1cHEoCvfqXh5LI5suUfeB7WQciF/9UKq6RlrV3y PHxw== X-Received: by 10.194.109.9 with SMTP id ho9mr31069626wjb.29.1429540292363; Mon, 20 Apr 2015 07:31:32 -0700 (PDT) Original-Received: from taylan.uni.cx (p200300514A37CC750213E8FFFEED36FB.dip0.t-ipconnect.de. [2003:51:4a37:cc75:213:e8ff:feed:36fb]) by mx.google.com with ESMTPSA id js3sm27524692wjc.5.2015.04.20.07.31.30 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Apr 2015 07:31:31 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Mon, 20 Apr 2015 08:42:58 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::231 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:185702 Archived-At: Stefan Monnier writes: >> A user is likely to expect everything defined by a package to be >> available during the execution of their init.el; the failure to meet >> this expectation is why we get so many confused users asking for help, >> receiving the answer "just put (package-initialize) at the top of your >> .emacs". > > But the current code in Emacs's "master" solves this problem by adding > "(package-initialize)" in the user's ~/.emacs. I had not realized this is already implemented. I generally feel uncomfortable about a tool automatically editing a file that I assume to have control over, but maybe that's fine. A concrete problem I can think of is when one has some settings for package.el in their init file, then Emacs ends up putting (package-initialize) at the top, when it should be after the package related settings. Is this not a problem? Other than that, it simply feels wrong to "solve" the problem with a trick like this as if initializing packages after init.el is the normal case, when the normal case is that init.el assumes presence of installed packages. That is, behavior is broken by default, but gets auto-fixed with a trick like this. WTF? It might be simple to implement, but conceptually it's rather confusing. One might argue it doesn't get conceptually any simpler because there's simply one init.el and it's agnostic towards package.el, but that's both wrong (packages are automatically initialized after loading init.el if it hasn't been done there) and a sign of the package system being crudely bolted on top of existing machinery. That's stinky engineering. I hope I'm not coming off as religious. >> If nobody sees any disadvantages, and nobody beats me to it, I might >> start working on implementing the solution that separates pre-package >> configuration from normal configuration, including Customize. > > I don't really know what solution you're referring to. But so far > I haven't seen any solution proposed that's really better than > what we already have. Splitting pre-package-initialization configuration from normal configuration. (Here "configuration" refers to the user's init file as well as Customize.) Making Emacs init look like: 1. pre-package-init.el, & Customize settings in it (or loading `package-custom-file') 2. package-initialize 3. init.el, & Customize settings in it (or loading `custom-file') This entails extending Customize functionality to offer something like a :pre-package-init flag which tells the system to write customization for the relevant defcustom into `package-custom-file' (falling back to pre-package-init.el) instead of `custom-file' (falling back to init.el). Yes, this is a more involved solution, but it brings some structure into Emacs initialization with regard to the role of the package system, and its interaction with Customize. By the way, I just noticed our support for default.el and site-start.el. I guess said separation of pre- and post-package-init configuration would be applied to those as well if we were being idealistic, though I think it should be fine to leave that be and only load default.el and site-start.el after package initialization. Or can anyone think of valid use-cases for a site admin to hook in some Elisp before users' package initialization? Taylan