Andy Wingo <wi...@pobox.com> writes:
> Hi Marek,
>
> On Sat 29 Jan 2011 13:13, Marek Kubica <ma...@xivilization.net> writes:
>
>> What about "the same directory that the file is in"? The point is, when
>> writing scripts that become larger than one file, splitting them into
>> modules becomes immensely painful because the modules cannot find each
>> other.
>
> For what purpose? If you are using modules, they are already in one
> global namespace, the various roots of which are in the %load-path
> and/or %load-compiled-path. (resolve-module '(foo bar)) should work
> regardless of what file calls it.
If the modules are installed, that's true. What if they are not?
Even if all of the non-installed modules are in a single tree, things
are a bit fiddly. For work from a REPL or from Geiser, you can put
(set! %load-path (cons "whatever" %load-path))
in ~/.guile, and
(load (in-vicinity (getenv "HOME") ".guile"))
in ~/.guile-geiser, but this doesn't do the job for scripts that want to
use those modules. (Because scripts do not load ~/.guile.)
For scripts that use uninstalled modules, then, some kind of solution is
needed; ideally one that works for both 1.8 and 1.9/2.0, allows the code
needed to live in a single common file, rather than duplicated at the
top of each script; and continues to work if the script+module tree as a
whole is moved to a different place in the filesystem. Also I think
it's preferable if the solution is a Guile one, as opposed to based on
the #! line, or needing a shell script wrapper.
> Perhaps you are interested in `load', which is problematic regarding
> compiled files; for example when loading from a compiled file, how will
> `load' know what is the current directory? Note that .go files are
> installed to e.g. /usr/lib64/guile, while source is in /usr/share/guile.
Good point, thanks for the reminder about that. But (for 1.9/2.0)
`include' will always be well-defined and reliably relative to the
containing file's name, won't it?
Regards,
Neil
