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: Sun, 19 Apr 2015 09:11:02 +0100 Message-ID: References: <87383xk4ia.fsf@taylan.uni.cx> <87pp71ia87.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=001a11c243e2bf63e405140f5a25 X-Trace: ger.gmane.org 1429431077 19412 80.91.229.3 (19 Apr 2015 08:11:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Apr 2015 08:11:17 +0000 (UTC) Cc: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= , Kaushal , Stefan Monnier , emacs-devel To: Philipp Stephani Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 19 10:11: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 1YjkJr-0001BN-1c for ged-emacs-devel@m.gmane.org; Sun, 19 Apr 2015 10:11:11 +0200 Original-Received: from localhost ([::1]:47786 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjkJq-0002f0-6c for ged-emacs-devel@m.gmane.org; Sun, 19 Apr 2015 04:11:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjkJl-0002es-M8 for emacs-devel@gnu.org; Sun, 19 Apr 2015 04:11:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YjkJk-0004eY-8q for emacs-devel@gnu.org; Sun, 19 Apr 2015 04:11:05 -0400 Original-Received: from mail-lb0-x22a.google.com ([2a00:1450:4010:c04::22a]:34365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YjkJj-0004eN-S1 for emacs-devel@gnu.org; Sun, 19 Apr 2015 04:11:04 -0400 Original-Received: by lbcga7 with SMTP id ga7so110321821lbc.1 for ; Sun, 19 Apr 2015 01:11:03 -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=s3OeYLMVikhYmnc341hzp+6Qk0Twd48F1/bLZPpjVqA=; b=Jw/5Yx2CAYw04lKVAxjvusfxFC3D0ZdwY4HsmhCpUUr+F0Q6d6bO77EKziRssJ4/z9 6EHsjbxvC5mDJ10WTPwHdM9gVgLTvSMwb0te1V+7gL87dMly2sqMezUYFTZWEBprnTOe 9Vrr2Vpm5F5nZxjR7UpzEN19f7rI7awBqRNA5gTs9G4B+yymyPl99/223QcGGK1lKpOV ov0jc5wyZnztyT1XnoPftyTmzeNmYxNprUhtK8MN6eN8vDetysAeGjwhxKUDg5HcuXte UjZqralfLi5LQoW2hOwuOvxIan/ux7Rg5uEUdO+z6QmrKXamNTG0Mc330m87pAIo+0G8 pxzg== X-Received: by 10.152.7.239 with SMTP id m15mr10626174laa.95.1429431063108; Sun, 19 Apr 2015 01:11:03 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Sun, 19 Apr 2015 01:11:02 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Sun, 19 Apr 2015 01:11:02 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: e5lEDOwPHVgW98J4K6Qw8lbFZ6I X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22a 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:185660 Archived-At: --001a11c243e2bf63e405140f5a25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 19, 2015 7:44 AM, "Philipp Stephani" wrote: > > > > Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer schrieb = am Sa., 18. Apr. 2015 um 20:04 Uhr: >> >> Stefan Monnier writes: >> >> > I think all those discussions are missing the point. >> > If we want to improve the system to the point of considering adding ne= w >> > init files, then we should try and fix other problems at the same time= . >> > >> > So here's one of the larger problems: >> > >> > How can we make the system work such that the user can: >> > - Use customize to set package-user-dir, package-pinned-packages, etc... >> > - Use customize to configure a variable which has a :require which loads >> > a file that's only available after calling package-initialize. >> > The first requires package-initialize to be called late, the second >> > requires package-initialize to be called early. >> > >> > Maybe a solution is to simply make customize-set-variables lazier, so >> > that variables with a :require see their setting delayed to after >> > package-initialize was called. Or else, have package-initialize be >> > called by customize-set-variables. Or... >> >> I'm not sure if this isn't an orthogonal problem, but indeed as someone >> who doesn't use Customize I didn't think about it at all, and know >> little about it so excuses in advance for ignorance. >> >> How about Customize being "smart" and separating package-related >> configurations from other ones? I don't know how hard it would be to >> implement, but it feels like the right design; obviously package related >> customization should be applied before package-initialize, but all other >> customization should be applied after package-initialize, since it's a >> configuration system, meaning it should be one layer above the package >> system, going purely by intuition. >> >> So startup would look like: >> >> 1. pre-package-init.el >> 2. Package related customization. >> 3. package-initialize >> 4. init.el >> 5. All other customization. >> >> Would that work? > > > I think that would be a good solution, although I'd modify it a bit: > > 1. Contents of init.el before applying customizations. I'm afraid this step is already a problem. If these initial contents contain a (require 'some-package), the user will be given an error during initialization. That's why Taylan's solution has an extra file. It's annoying, but necessary. > 2. Applying customizations, either inline in init.el or by loading custom.el from init.el > 2.a. Package related customization > 2.b. package-initialize > 2.c. All other customization > 3. Rest of init.el > > That would be closer to the current behavior and eliminate the need for pre-package-init.el. It would be so close to the current behaviour that the problem wouldn't be solved. ;-) The point here is that it needs to just work for the less knowledgeable user. We can't expect them to move their call to (require 'some-package) until after the custom.el snippet is loaded. Not to mention, they might not even have such a snippet. --001a11c243e2bf63e405140f5a25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Apr 19, 2015 7:44 AM, "Philipp Stephani" <p.stephani2@gmail.com> wrote:=
>
>
>
> Taylan Ulrich Bay=C4=B1rl=C4=B1/Kammer <taylanbayirli@gmail.com> schrieb am Sa., 18. Apr. 20= 15 um 20:04=C2=A0Uhr:
>>
>> Stefan Monnier <mon= nier@IRO.UMontreal.CA> writes:
>>
>> > I think all those discussions are missing the point.
>> > If we want to improve the system to the point of considering = adding new
>> > init files, then we should try and fix other problems at the = same time.
>> >
>> > So here's one of the larger problems:
>> >
>> > How can we make the system work such that the user can:
>> > - Use customize to set package-user-dir, package-pinned-packa= ges, etc...
>> > - Use customize to configure a variable which has a :require = which loads
>> >=C2=A0 =C2=A0a file that's only available after calling pa= ckage-initialize.
>> > The first requires package-initialize to be called late, the = second
>> > requires package-initialize to be called early.
>> >
>> > Maybe a solution is to simply make customize-set-variables la= zier, so
>> > that variables with a :require see their setting delayed to a= fter
>> > package-initialize was called.=C2=A0 Or else, have package-in= itialize be
>> > called by customize-set-variables.=C2=A0 Or...
>>
>> I'm not sure if this isn't an orthogonal problem, but inde= ed as someone
>> who doesn't use Customize I didn't think about it at all, = and know
>> little about it so excuses in advance for ignorance.
>>
>> How about Customize being "smart" and separating package= -related
>> configurations from other ones?=C2=A0 I don't know how hard it= would be to
>> implement, but it feels like the right design; obviously package r= elated
>> customization should be applied before package-initialize, but all= other
>> customization should be applied after package-initialize, since it= 's a
>> configuration system, meaning it should be one layer above the pac= kage
>> system, going purely by intuition.
>>
>> So startup would look like:
>>
>> =C2=A0 1. pre-package-init.el
>> =C2=A0 2. Package related customization.
>> =C2=A0 3. package-initialize
>> =C2=A0 4. init.el
>> =C2=A0 5. All other customization.
>>
>> Would that work?
>
>
> I think that would be a good solution, although I'd modify it a bi= t:
>
> 1. Contents of init.el before applying customizations.

I'm afraid this step is already a problem. If these init= ial contents contain a (require 'some-package), the user will be given = an error during initialization.

That's why Taylan's solution has an extra file. It&#= 39;s annoying, but necessary.

> 2. Applying customizations, either inline in init.el or= by loading custom.el from init.el
> =C2=A0 2.a. Package related customization
> =C2=A0 2.b. package-initialize
> =C2=A0 2.c. All other customization
> 3. Rest of init.el
>
> That would be closer to the current behavior and eliminate the need fo= r pre-package-init.el.=C2=A0

It would be so close to the current behaviour that the probl= em wouldn't be solved. ;-)

The point here is that it needs to just work for the less kn= owledgeable user. We can't expect them to move their call to (require &= #39;some-package) until after the custom.el snippet is loaded. Not to menti= on, they might not even have such a snippet.

--001a11c243e2bf63e405140f5a25--