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: Fri, 16 Nov 2012 16:38:35 -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> <87r4nts7lq.fsf@tines.lan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=e89a8fb201ca04a2c704cea397c6 X-Trace: ger.gmane.org 1353101925 19869 80.91.229.3 (16 Nov 2012 21:38:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 16 Nov 2012 21:38:45 +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 22:38:56 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 1TZTck-0007G5-VD for guile-devel@m.gmane.org; Fri, 16 Nov 2012 22:38:55 +0100 Original-Received: from localhost ([::1]:35121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZTca-0004x9-N8 for guile-devel@m.gmane.org; Fri, 16 Nov 2012 16:38:44 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:38760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZTcW-0004wt-0Q for guile-devel@gnu.org; Fri, 16 Nov 2012 16:38:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TZTcS-00033i-Mz for guile-devel@gnu.org; Fri, 16 Nov 2012 16:38:39 -0500 Original-Received: from mail-oa0-f41.google.com ([209.85.219.41]:45713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TZTcS-00032C-FV; Fri, 16 Nov 2012 16:38:36 -0500 Original-Received: by mail-oa0-f41.google.com with SMTP id k14so3646162oag.0 for ; Fri, 16 Nov 2012 13:38:35 -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=sCizfGhshuCyErJnsbV3FKKcUNjEHjw6kJeHv3fZ02g=; b=VtpkyH0ubbifHeALw36unneTk7R4xIyTX6wKVa1QLIhI6yJvI4QNzhQsWjx6haOXLH dqbSx92aDnOxxNkBNKfRLetVD/D0c+ulGHJvfoREkMOpp03fIO209s4jaWbI650Yz/q1 m47xIqGE26xojT9AiV7bQVPxsQNOIRu93daISKai5+VijJEAZuSb5EVXobS9UtSMbbTX OlAklsr9c3OKxg7n81bwCyqcMImT0Ya1w+9Lp6iUCK3GRRiEY787eAgYtBCfkhQxYUBy uxEc7VGJPDDdNmBvagjrMFmv06iLSDyPXkXgdAEH44gvOtNpuNXfXgXlEfG/SUHvhIVf QQ4Q== Original-Received: by 10.60.14.200 with SMTP id r8mr5163411oec.45.1353101915496; Fri, 16 Nov 2012 13:38:35 -0800 (PST) Original-Received: by 10.76.120.236 with HTTP; Fri, 16 Nov 2012 13:38:35 -0800 (PST) In-Reply-To: <87r4nts7lq.fsf@tines.lan> X-Google-Sender-Auth: JbUfQwVWufQaZawYynUApR7sPHU X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.219.41 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:15187 Archived-At: --e89a8fb201ca04a2c704cea397c6 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 16, 2012 at 1:52 PM, Mark H Weaver wrote: > Hi Noah, > Hello, > In general, I think the idea of requiring people to write scheme code to > manipulate %load-path (and other settings) is a fine approach. Maybe > you're right that this is better than adding a bunch of new environment > variables. > However, neither init.scm nor ~/.guile is sufficient for this job. > init.scm is site-wide, and generally only editable by root, and ~/.guile > is only run by interactive REPL sessions. So to do as you suggest, we'd > need to add another user-specific file that is read when initializing > guile, even for non-interactive sessions. > Ah, I didn't realize that was an issue. I was modeling this on what Emacs does, but it doesn't run in batch mode very much. Three configuration files with different meanings seems like a lot, but there's no other way that preserves backwards compatibility. Maybe we could use the $XDG_CONFIG directory for it (not that I like their default value). > Also, note that this still doesn't solve our immediate problem regarding > Guildhall and SRFIs in a backward-compatible way, so we still need to > support the "..." marker for the next 7-8 years, unless someone has a > better suggestion. > I see your point, but leaving it like this doesn't fix anything that isn't already broken; is that right? If so, I think we could justify saying that people need to upgrade to get the new behavior, especially if the complexity of supporting old versions is high. Noah --e89a8fb201ca04a2c704cea397c6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Nov 16, 2012 at 1:52 PM, Mark H Weaver <mhw@netris.org>= wrote:
Hi Noah,
=A0
Hello,
=A0
In general, I think the idea of requiring people to writ= e scheme code to
manipulate %load-path (and other settings) is a fine approach. =A0Maybe
you're right that this is better than adding a bunch of new environment=
variables.=A0

However, neither init.scm nor ~/.guile is sufficient for this job.
init.scm is site-wide, and generally only editable by root, and ~/.guile is only run by interactive REPL sessions. =A0So to do as you suggest, we= 9;d
need to add another user-specific file that is read when initializing
guile, even for non-interactive sessions.

Ah, I di= dn't realize that was an issue. I was modeling this on what Emacs does,= but it doesn't run in batch mode very much. Three configuration files = with different meanings seems like a lot, but there's no other way that= preserves backwards compatibility. Maybe we could use the $XDG_CONFIG dire= ctory for it (not that I like their default value).
=A0
Also, note that this still doesn't solve our immediate problem regardin= g
Guildhall and SRFIs in a backward-compatible way, so we still need to
support the "..." marker for the next 7-8 years, unless someone h= as a
better suggestion.

I see your point, but leaving i= t like this doesn't fix anything that isn't already broken; is that= right? If so, I think we could justify saying that people need to upgrade = to get the new behavior, especially if the complexity of supporting old ver= sions is high.

Noah

--e89a8fb201ca04a2c704cea397c6--