Thanks Eli - I think I have have better understanding of the issue now... see below. <div class="gmail_quote">On Sun, Oct 4, 2009 at 10:40 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> [The only thing that is vaguely close to the same area is that planet adds the concept of a `package' (which is, IIUC, what Carl's tool uses to come up with a symbolic name) -- so you could think of an alternative form to require code from the current package's root, but this would hard-wire a "package == project" concept, and it still won't apply to code that is outside of planet packages.] </blockquote><div> Agreed - project might or might not equal packages. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div> > It helps define packages which are referred via symbols. </div>The symbolic way to reference them is not related here -- what would be is some form like I mentioned above, which can work relatively to the current package's root. </blockquote><div> When the packages are small, the relative paths are isolated within the package, so potential changes are small and less disruptive. That's why I mentioned it (and main.ss). I found that having a big project, like having a big module or a big procedure, is simply harder to manage without intermediate abstractions. </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">because that relative string is not a universal reference to that specific file. Carl's package solves that by coming up with a symbolic name that would always refer to that file, and it does so using a `planet' symbolic name (which is exactly why it's limited to planet packges). You could imagine a similar tool (or an extension of Carl's tool) that works for installed collections too, but you'd still be left with random code in your filesystem that is in neither -- since in that case there is no symbolic way to refer to the file without specifying its full path. </blockquote><div> When I first start writing large programs in PLT I was directed to make use the planet system for organization. It definitely take me a while to figure out how to make it work, but so far things mostly work well. That being said, having the ability to handle projects similar to other IDEs such as Visual Studio or XCode makes sense for PLT. I would love to be able to open all files for a project at once. The trouble with config file is of course you would have to keep it in sync. That's easier with DrScheme than with emacs/mzscheme since you can make DrScheme to maintain it automatically (like Visual Studio, XCode, etc), but I agree maintaining it in one spot is easier than having to modify relative paths all over the modules unless the developer has already taken the care to organize the modules. Anyhow, I digress. Going back to your question - how does the following look to you? ;; load the config file, which provides a list of symbols to the file path mappings that you can explicitly require (and implicitly requires all if you provide no symbols) (require (config-in "config.ss" my-module-foo my-module-bar ...)) And it seems that having the ability to reset the current-load-relative-directory would be useful too if you do not want to maintain a config file but would like to have uniform relative paths against a base directory. ;; reset the base-directory to the parent directory, and then load the rest of the files relative to the new base directory. (require (base-in ".." "my/module/foo.ss" "my/module/bar.ss" ...)) My 2 cents. Cheers. yc </div></div>