[plt-scheme] PlaneT, plts and distributing software.

> > It is possible in Java through jars (and classpaths),
> Java's classpath is very much like PLTCOLLECTS, and (IIRC) suffers
Java allows setting the classpath without changing the environment,
through a commandline switch.

> > 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
AFAIR, Windows uses the location of the binary file, which is not the
same as what MzScheme does, because in the Windows case the binary
file IS the application, and in PLT the binary file is just a tool
used to run the application. The perl comparison is much better, see
below.

> > 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.)
No really. When you do "perl myapp.pl", it will look for libraries
under the directory of myapp.pl, and only if they are not found there
it will look further under the standard libraries path (which is near
the perl executabe).

> > >  (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
I still don't see the harm of adding another switch. Alternatively,
the path of the first/last/all file supplied with -f can be added to
the collects path.

> already.  What you want could also be done with:
>  mzscheme -f ".../myenv.scm"
This is what I'll use (adding it as another -f and not as a load from
the main file IS a nice suggestion), but it still feels like a hack.

Also, correct me if I'm wrong, but this will work only for MzScheme,
right? Not for DrScheme or mzc, which will still make change the env
variable in order to use them.. (which is another issue).

> > 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.)
Why?


> > 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?
No. I also had the code on a DiskOnKey and on my email. I used the
webserver because it was the fastest way to get it. But this is not
the point. The point is I want to be able to take ALL my required code
with me, and I want it to be as easy as taring a directory and putting
the result somewhere, without having to think about other locations I
might have code in (such as the planet cache and my addons directory,
which I didn't even knew existed).

> 2. By getting rid of the planet stuff, you also gave up on automatic
>   updates.
This is a pitty.

> > 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.)
Don't get me wrong. I am not against planet, I think it is a very nice
tool, and I am going to put my code there once it's ready for release.
But (and I'm not talking about my current project, which I am not that
concerned about its availability anyhow) as it stands now, when there
is only one planet server which is controlled and maintained by the
PLT team, it just can not be used in commercial settings - it's not
reliable enough.

The ability to easily put planet mirrors, and have the code access a
specific mirror, will be a very nice addon.
Same for the ability to configure the application (without
midifications of source code) to access planet only when a suitable
collect can not be found localy, or never at all (automatic updates
can be considered a security risk).


Yoav