[plt-scheme] PlaneT, plts and distributing software.
I'll ignore the planet issues, since Jacob talked about that.
On Oct 26, Yoav Goldberg wrote:
> I never said I want one package in one place and the other in a
> completely different place (although this could be nice). I just
> said I wanted this "standard place" you talk about to be extended
> somewhat, to include also a collects directory which is just under
> the path of my "main" scheme code, so I could distribute my software
> + all of its dependencies together, without having to think much
> about how to do it.
For that, you need to either set PLTCOLLECTS, or change the parameter
like you're already doing. I don't see any harm in doing that -- you
can provide a single top-level file that will set the search path
using (this-expression-source-directory).
> It is possible in Java through jars (and classpaths),
Java's classpath is very much like PLTCOLLECTS, and (IIRC) suffers
from the same problems. Jar files just make their contents into one
unit which you can get by using relative paths.
> it's possible on natively compiled language (at least on windows) -
> the dlls are first looked for in the application directory, and only
> then in the "standard places" (path, system directories, etc),
I don't remember exactly how the Windows mechanism works -- it uses
either the location of the binary file (which is what MzScheme does if
there is no PLTHOME environment variable), or perhaps it uses the
"Start In" property which basically changes the current directory
before running your application. The last one is like using
(current-directory) to require things, and sounds like a very shaky
way to require libraries since it makes the library lexical
specification depend on a dynamic run-time value.
> it's possible with Perl (again, libraries are first searched on the
> application directory, only then on the perl/lib directory...
(same as the second point above.)
> > (module foo mzscheme
> > (require (lib "blah.ss" "blah"))
> > ...)
> > how exactly should mzscheme know that "blah" is in your cd drive?
> One solution for it would be a (god forbid) new command line
> options, something like --additional-collect-paths
> <list-of-additional-collect-paths>
The cynicism is unnecessary -- the command line is very packed
already. What you want could also be done with:
mzscheme -f ".../myenv.scm"
and putting this in that file:
(require (lib "etc.ss"))
(current-library-collection-path
(cons (this-expression-source-directory)
(current-library-collection-path)))
If you see a reason that this is insufficient or unacceptable, then
file a feature request.
> No, I would be stuck in a *slightly-worse* way, as I'll have to
> change my application code to make it run on new computers, which is
> not the case with the whole PLT being dumped (where my code will
> still work).
(This is a very naive view.)
> I am (currently) staying at 3 different places (my house, my parents
> house, and my girlfriends parents house), and have a different
> computer on each of them. I work on all of them. Just the other day
> I came to my parents house, downloaded the code I'm currently
> working on from my web server, and hit the "run" burron on
> DrScheme. It didn't work - PLaneT was down. Doh! I thought, how
> stupid of me! And the next thing I did after PLaneT came back up was
> to download the memoized package, put under the src tree of my
> current code, and get rid of all that planet require.
1. If your webserver was dead and planet was alive, then you'd have
only the memoize library available. Isn't this a reason to move
stuff to planet?
2. By getting rid of the planet stuff, you also gave up on automatic
updates.
> Please note the "on a new computer" part of the sentence. I realize
> that once it's in the cache it will work fine. But what if it's not?
(Same as my inability to run your package from a new computer that
cannot connect to wherever you put it.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!