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.lav...@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 <m...@netris.org> wrote: > >> Hi Andreas, >> >> Andreas Rottmann <a.rottm...@gmx.at> writes: >> >> > l...@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 >> >> >
