Re: Adding to the end of the load path

[Noah Lavine <noah.b.lavine@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 --]