From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.devel Subject: Re: Adding to the end of the load path Date: Thu, 15 Nov 2012 19:10:58 -0500 Message-ID: References: <87sj8o20v0.fsf@googlemail.com> <87liecucrz.fsf@delenn.home.rotty.xx.vu> <87k3tpkyeg.fsf@gnu.org> <87a9uied25.fsf@delenn.home.rotty.xx.vu> <87fw4atrjz.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8fb2013a26b10004ce919a92 X-Trace: ger.gmane.org 1353024672 28536 80.91.229.3 (16 Nov 2012 00:11:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2012 00:11:12 +0000 (UTC) Cc: =?ISO-8859-1?Q?Ludovic_Court=E8s?= , guile-devel To: Mark H Weaver Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Nov 16 01:11:22 2012 Return-path: Envelope-to: guile-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 1TZ9Wf-0006BT-PN for guile-devel@m.gmane.org; Fri, 16 Nov 2012 01:11:17 +0100 Original-Received: from localhost ([::1]:52048 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZ9WV-0007WK-Kv for guile-devel@m.gmane.org; Thu, 15 Nov 2012 19:11:07 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50832) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZ9WQ-0007SR-UM for guile-devel@gnu.org; Thu, 15 Nov 2012 19:11:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZ9WN-0004Yx-Rt for guile-devel@gnu.org; Thu, 15 Nov 2012 19:11:02 -0500 Original-Received: from mail-ob0-f169.google.com ([209.85.214.169]:56065) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZ9WN-0004Yr-KY; Thu, 15 Nov 2012 19:10:59 -0500 Original-Received: by mail-ob0-f169.google.com with SMTP id lz20so2564928obb.0 for ; Thu, 15 Nov 2012 16:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=trlJr786qSKrN82HCnA92pP33epjG+XhgdvhmTKSEwM=; b=x7/uS6PRYyEp9BahIgEjIaB26dnuFH5nrs1SkNvpzWBmPYqnxEND9ZvBstTwsxQsK7 POaEgQEqooHe8rJGurhzeKzz7K/OvaWjMqpJv3BSnblgBmQuuHsjVkCg7zF0vraELnC9 qKBsRsANfRh0qUACNBSNFlBT2E7zDuzhisgt3pjniEbRLGxnGUqBFPmT1OD+6nVXUsJ4 fK7OSOpiDDNJzeYgOai48TxUXZkK6Ru1yhxfUzB/t6UcRy8M9wNmyubRYYzEnwiGqozA tOwe79A8f3gsv5oT8XsrCY5THAFAlngd0InO+yJwgeRL6Sj6bA/u4u9sZVkxizaXkG33 wRqw== Original-Received: by 10.60.12.106 with SMTP id x10mr2480109oeb.10.1353024658649; Thu, 15 Nov 2012 16:10:58 -0800 (PST) Original-Received: by 10.76.120.236 with HTTP; Thu, 15 Nov 2012 16:10:58 -0800 (PST) In-Reply-To: <87fw4atrjz.fsf@tines.lan> X-Google-Sender-Auth: ZBAzmP7XxfmQG9A_OAqxarYsakg X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.214.169 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:15178 Archived-At: --e89a8fb2013a26b10004ce919a92 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, This is coming late in the discussion, but I'd like to suggest a somewhat different approach. I hope this is helpful. It seems to me that in the end, the module-lookup system may need to be more complex than having regular and suffix lookup paths. For instance, one of the big concerns here was reducing the number of stat() calls. What if we know that some load directories only contain certain modules? We might want a way for the user to say "all the (foo ...) modules live in ~/foo, but you don't have to look for any other modules there". Or what if I want to use a backup version of a module that's also included in the regular Guile distribution, because I haven't ported my code to a new version yet (yes, I should use module versions, but I don't)? There might be more complicated scenarios too. Given that the module-lookup system is fundamentally complicated, I'm going to suggest that we *don't* try to make it all configurable by environment variables. If people want full control of lookups, they can write a site-wide Guile init file or a personal ~/.guile. The regular load-path would still be part of the system, and that would be configurable by an environment variable, so legacy setups would continue to work. However, I'd be happy saying that if you wanted to access all of the functionality, you need to write Scheme code. Let's start by adding Scheme interfaces to the functionality we want, and maybe not worry about environment variables if they're complicated. What do you think? Noah On Thu, Nov 15, 2012 at 5:44 PM, Mark H Weaver wrote: > Hi Andreas, > > Andreas Rottmann writes: > > > ludo@gnu.org (Ludovic Court=E8s) writes: > > > >> I pretty much like Mark=92s suggestion of using =91...=92 as a special= marker, > >> even though that=92s a valid file name. > >> > > Well, there's a workaround -- specifying "./..." as an "escape sequence= " > > for "..." if you really need to have a three-dot relative directory in > > the path. > > > >> How would that work for you? > >> > > I would like the approach using separate _SUFFIX variables better, as i= t > > doesn't have this special case. > > As I wrote earlier, I certainly agree that the _SUFFIX approach is > cleaner. Unfortunately, we need a solution that will work nicely with > earlier versions of Guile. > > > While I don't think the special case > > will be a problem for a user setting the environment variables > > themselves, if you want to set them programatically, you now have to > > consider treat "..." specially, escaping it like mentioned above, to be > > general. > > Note that PATH-style variables are already not general, because they > provide no way to include filenames containing ':' (a colon). > > In general, it's best to avoid setting GUILE_LOAD_PATH programmatically, > because it will affect more than just the instance of Guile you > intended; it will also affect any subprocesses that use Guile. It's > better to use -L which is fully general without any special cases, or to > modify %load-path within the program itself. > > > However, I can live with that, but maybe we can have it both > > ways: > > > > - Add the _SUFFIX environment variables, making it clear in the docs > > that they are supported only from Guile 2.0.7 onward. > > Yes, I agree this is a good idea. > > > - Additonally, add "..." as a special marker, but mention it is just > > provided to support Guile < 2.0.7, and should not be used in code tha= t > > needs to depend on Guile 2.0.7 or newer for other reasons > > (e.g. reliance on another added feature or significant bugfix). > > Again, these environment variables are not specific to any particular > piece of code. They are usually associated with an entire user account. > > > I'm not sure how the deprecation strategy is employed exactly, but we > > could mark the "..." feature as deprecated right away, or at least in > > master, and remove it in 2.2 or 2.4. > > I don't think we can mark it deprecated until versions of Guile older > than 2.0.7 have become very rare, which won't be until at least 2017 > (due to Ubuntu 12.04 LTS), and then it will need to be deprecated for a > couple more years before we can get rid of it entirely. Therefore, I > think it's premature to emphasize the transient nature of the "..." > marker. Like it or not, we'll probably be stuck with it for 7 or 8 > years. > > Does that make sense? > > Regards, > Mark > > --e89a8fb2013a26b10004ce919a92 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello,

This is coming late in the discussion, but I'= d like to suggest a somewhat different approach. I hope this is helpful.

It seems to me that in the end, the module-lookup sy= stem may need to be more complex than having regular and suffix lookup path= s. For instance, one of the big concerns here was reducing the number of st= at() calls. What if we know that some load directories only contain certain= modules? We might want a way for the user to say "all the (foo ...) m= odules live in ~/foo, but you don't have to look for any other modules = there". Or what if I want to use a backup version of a module that'= ;s also included in the regular Guile distribution, because I haven't p= orted my code to a new version yet (yes, I should use module versions, but = I don't)? There might be more complicated scenarios too.

Given that the module-lookup system is fundamentally co= mplicated, I'm going to suggest that we *don't* try to make it all = configurable by environment variables. If people want full control of looku= ps, they can write a site-wide Guile init file or a personal ~/.guile. The = regular load-path would still be part of the system, and that would be conf= igurable by an environment variable, so legacy setups would continue to wor= k. However, I'd be happy saying that if you wanted to access all of the= functionality, you need to write Scheme code. Let's start by adding Sc= heme interfaces to the functionality we want, and maybe not worry about env= ironment variables if they're complicated.

What do you think?
Noah



On Thu, Nov 1= 5, 2012 at 5:44 PM, Mark H Weaver <mhw@netris.org> wrote:
Hi Andreas,

Andreas Rottmann <a.rottmann@gmx.at= > writes:

> ludo@gnu.org (Ludovic Court=E8s) w= rites:
>
>> I pretty much like Mark=92s suggestion of using =91...=92 as a spe= cial marker,
>> even though that=92s a valid file name.
>>
> Well, there's a workaround -- specifying "./..." as an &= quot;escape sequence"
> for "..." if you really need to have a three-dot relative di= rectory in
> the path.
>
>> How would that work for you?
>>
> I would like the approach using separate _SUFFIX variables better, as = it
> doesn't have this special case.

As I wrote earlier, I certainly agree that the _SUFFIX approach is cleaner. =A0Unfortunately, we need a solution that will work nicely with earlier versions of Guile.

> While I don't think the special case
> will be a problem for a user setting the environment variables
> themselves, if you want to set them programatically, you now have to > consider treat "..." specially, escaping it like mentioned a= bove, to be
> general.

Note that PATH-style variables are already not general, because they<= br> provide no way to include filenames containing ':' (a colon).

In general, it's best to avoid setting GUILE_LOAD_PATH programmatically= ,
because it will affect more than just the instance of Guile you
intended; it will also affect any subprocesses that use Guile. =A0It's<= br> better to use -L which is fully general without any special cases, or to modify %load-path within the program itself.

> However, I can live with that, but maybe we can have it both
> ways:
>
> - Add the _SUFFIX environment variables, making it clear in the docs > =A0 that they are supported only from Guile 2.0.7 onward.

Yes, I agree this is a good idea.

> - Additonally, add "..." as a special marker, but mention it= is just
> =A0 provided to support Guile < 2.0.7, and should not be used in co= de that
> =A0 needs to depend on Guile 2.0.7 or newer for other reasons
> =A0 (e.g. reliance on another added feature or significant bugfix).
Again, these environment variables are not specific to any particular=
piece of code. =A0They are usually associated with an entire user account.<= br>

> I'm not sure how the deprecation strategy is employed exactly, but= we
> could mark the "..." feature as deprecated right away, or at= least in
> master, and remove it in 2.2 or 2.4.

I don't think we can mark it deprecated until versions of Guile o= lder
than 2.0.7 have become very rare, which won't be until at least 2017 (due to Ubuntu 12.04 LTS), and then it will need to be deprecated for a
couple more years before we can get rid of it entirely. =A0Therefore, I
think it's premature to emphasize the transient nature of the "...= "
marker. =A0Like it or not, we'll probably be stuck with it for 7 or 8 years.

Does that make sense?

=A0 =A0 Regards,
=A0 =A0 =A0 Mark


--e89a8fb2013a26b10004ce919a92--