From: Noah Lavine <noah.b.lavine@gmail.com>
To: Noah Lavine <noah.b.lavine@gmail.com>
Cc: "Mark H Weaver" <mhw@netris.org>,
"Ludovic Courtès" <ludo@gnu.org>,
guile-devel <guile-devel@gnu.org>
Subject: Re: Adding to the end of the load path
Date: Fri, 16 Nov 2012 09:00:10 -0500 [thread overview]
Message-ID: <CA+U71=O0om4KaRkd4feWZZpSQuFZ9=Qj7E2tmUoF4Lg0foEx0A@mail.gmail.com> (raw)
In-Reply-To: <CA+U71=NhCduytPC6E-K8gHHu21BPMrAEhtD70=s0+uH8q7Uqog@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5464 bytes --]
And replying to myself, I remembered something else that had been in the
back of my mind: a while ago on this list, there was discussion of bundling
some modules with libguile, perhaps as static C arrays. This could make it
easier to embed Guile, as a program could embed all the modules it needs
and not have to worry about load-paths.
However, this is another extension to the module-lookup system which really
cannot be well-specified by environment variables. This is more evidence
for my theory that module-lookup is fundamentally too complicated to be
conveniently represented by environment variables.
Of course, I would be very happy to be proven wrong,
Noah
On Thu, Nov 15, 2012 at 7:10 PM, Noah Lavine <noah.b.lavine@gmail.com>wrote:
> 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 <mhw@netris.org> wrote:
>
>> Hi Andreas,
>>
>> Andreas Rottmann <a.rottmann@gmx.at> writes:
>>
>> > ludo@gnu.org (Ludovic Courtès) writes:
>> >
>> >> I pretty much like Mark’s suggestion of using ‘...’ as a special
>> marker,
>> >> even though that’s 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 it
>> > 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 that
>> > 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
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 6743 bytes --]
next prev parent reply other threads:[~2012-11-16 14:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-05 3:18 Adding to the end of the load path Ian Price
2012-11-08 1:03 ` Andreas Rottmann
2012-11-11 7:50 ` Mark H Weaver
2012-11-11 19:02 ` Andreas Rottmann
2012-11-11 21:51 ` Mark H Weaver
2012-11-12 16:35 ` Bruce Korb
2012-11-13 21:04 ` Ludovic Courtès
2012-11-15 22:06 ` Andreas Rottmann
2012-11-15 22:37 ` Ludovic Courtès
2012-11-15 22:44 ` Mark H Weaver
2012-11-15 23:06 ` Ludovic Courtès
2012-11-16 0:10 ` Noah Lavine
2012-11-16 14:00 ` Noah Lavine [this message]
2012-11-16 18:06 ` Bruce Korb
2012-11-16 18:52 ` Mark H Weaver
2012-11-16 21:38 ` Noah Lavine
2012-11-28 23:12 ` [PATCH] Add parse-path-with-ellipsis, and use it for GUILE_LOAD_PATH et al Mark H Weaver
2012-11-28 23:46 ` Ludovic Courtès
2012-11-29 3:04 ` Mark H Weaver
2012-11-29 10:27 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+U71=O0om4KaRkd4feWZZpSQuFZ9=Qj7E2tmUoF4Lg0foEx0A@mail.gmail.com' \
--to=noah.b.lavine@gmail.com \
--cc=guile-devel@gnu.org \
--cc=ludo@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).