From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: Calling (package-initialize) sooner during initialization Date: Mon, 20 Apr 2015 17:01:40 +0100 Message-ID: References: <87383xk4ia.fsf@taylan.uni.cx> <87d22zi69k.fsf@taylan.uni.cx> <878udmj2gu.fsf@taylan.uni.cx> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113402e0a99b7805142a0bd3 X-Trace: ger.gmane.org 1429545762 32123 80.91.229.3 (20 Apr 2015 16:02:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Apr 2015 16:02:42 +0000 (UTC) Cc: Stefan Monnier , emacs-devel To: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 20 18:02:41 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 1YkE9g-0000Le-0T for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 18:02:40 +0200 Original-Received: from localhost ([::1]:54403 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkE9f-0001AK-7M for ged-emacs-devel@m.gmane.org; Mon, 20 Apr 2015 12:02:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59044) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkE8l-0000GS-DM for emacs-devel@gnu.org; Mon, 20 Apr 2015 12:01:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkE8j-0008Ca-LT for emacs-devel@gnu.org; Mon, 20 Apr 2015 12:01:43 -0400 Original-Received: from mail-la0-x236.google.com ([2a00:1450:4010:c03::236]:33585) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkE8j-0008CR-7p for emacs-devel@gnu.org; Mon, 20 Apr 2015 12:01:41 -0400 Original-Received: by layy10 with SMTP id y10so130421504lay.0 for ; Mon, 20 Apr 2015 09:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oVn/B1Bc0YfFnLKhv55fYGjqfk8JGrZb7f4aKxjloYA=; b=BF8Zqpn5RD72sJ3Sds+YF+WJri/FJvSiqEnGoyp5rDlQ1lP2X6s5cBKn1TQJQ9amdp mnWa3Tdkaad/6iqO2sNJt7qXXBf4773MAEVSx6A9anPjih62ybFF0oQF8hzF00HU57/L 0W+qr1kxE4T42bC48J2O+jEGbAgg2aSstF5/rgE2DkAtvBkhoNtPsRRtwCRAeCAJYBSn 3W8caKgEir5yZcz7oPHUnzX5R9TbJ455v7jpAZbqiC9dU4PNI64tdTfjqwa3btkIrKwR 3yDkzZqQz+MsT5/AWkLspXjL8B4LUpc5CPWnccq6vWmmmLIFBYulfStr4tYBM1ynrrDk uEDg== X-Received: by 10.112.29.180 with SMTP id l20mr15642854lbh.95.1429545700398; Mon, 20 Apr 2015 09:01:40 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Mon, 20 Apr 2015 09:01:40 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Mon, 20 Apr 2015 09:01:40 -0700 (PDT) In-Reply-To: <878udmj2gu.fsf@taylan.uni.cx> X-Google-Sender-Auth: JLUyfkW2GgKeTu4MxiHvM8NPwPg X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::236 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:185717 Archived-At: --001a113402e0a99b7805142a0bd3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 20, 2015 4:31 PM, "Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer" < taylanbayirli@gmail.com> wrote: > > 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. You're not the only one. Other people have voiced indignation. > 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? Slightly, yes. A person who does that sort of thing knows enough to understand they only need to comment out the added call to package-initialize. It would be preferable to not impose this on them though (which is why the whole discussion has been revived). > 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'm not against a better solution. > 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). I'm in favor of this. I would suggest you send a new email as a separate thread summarising what will be done, before you go through all the work (though that's up to you). Something similar to what you've just written here, with just a little bit more detail (like saying where the changes will be made) and written with a clear statement of the advantages (reconciling package.el, user code, and custom). > 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? I don't think separation needs to be applied to them. If they're currently run before package-initialize, just leave it like that. I don't know why a maintainer would want to run code after package-initialize, but if they want to do that they can use an after init hook. --001a113402e0a99b7805142a0bd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 20, 2015 4:31 PM, "Taylan Ulrich Bay=C4=B1rl=C4= =B1/Kammer" <taylanbayir= li@gmail.com> wrote:
>
> Stefan Monnier <monnier= @IRO.UMontreal.CA> 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 t= he top of your
> >> .emacs".
> >
> > But the current code in Emacs's "master" solves thi= s 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 fi= le
> that I assume to have control over, but maybe that's fine.

You're not the only one. Other people have voiced indign= ation.

> 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.=C2=A0 Is this not a problem?

Slightly, yes. A person who does that sort of thing knows en= ough to understand they only need to comment out the added call to package-= initialize. It would be preferable to not impose this on them though (which= is why the whole discussion has been revived).

> Other than that, it simply feels wrong to "solve&q= uot; the problem with a
> trick like this as if initializing packages after init.el is the norma= l
> case, when the normal case is that init.el assumes presence of install= ed
> packages.=C2=A0 That is, behavior is broken by default, but gets auto-= fixed
> with a trick like this.=C2=A0 WTF?=C2=A0 It might be simple to impleme= nt, but
> conceptually it's rather confusing.
>
> One might argue it doesn't get conceptually any simpler because th= ere's
> simply one init.el and it's agnostic towards package.el, but that&= #39;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<= br> > crudely bolted on top of existing machinery.=C2=A0 That's stinky e= ngineering.

I'm not against a better solution.

> 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.=C2= =A0 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.=C2=A0 (Here "configuration" refers to the use= r's init file as
> well as Customize.)=C2=A0 Making Emacs init look like:
>
> =C2=A0 =C2=A0 1. pre-package-init.el, & Customize settings in it (= or loading
> =C2=A0 =C2=A0 =C2=A0 =C2=A0`package-custom-file')
>
> =C2=A0 =C2=A0 2. package-initialize
>
> =C2=A0 =C2=A0 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 f= or
> the relevant defcustom into `package-custom-file' (falling back to=
> pre-package-init.el) instead of `custom-file' (falling back to ini= t.el).

I'm in favor of this. I would suggest you send a new ema= il as a separate thread summarising what will be done, before you go throug= h all the work (though that's up to you). Something similar to what you= 've just written here, with just a little bit more detail (like saying = where the changes will be made) and written with a clear statement of the a= dvantages (reconciling package.el, user code, and custom).

> By the way, I just noticed our support for default.el a= nd 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<= br> > site-start.el after package initialization.=C2=A0 Or can anyone think = of
> valid use-cases for a site admin to hook in some Elisp before users= 9;
> package initialization?

I don't think separation needs to be applied to them. If= they're currently run before package-initialize, just leave it like th= at. I don't know why a maintainer would want to run code after package-= initialize, but if they want to do that they can use an after init hook.

--001a113402e0a99b7805142a0bd3--