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

> If you put it all in a single directory and use relative paths, then
> things will work fine.  You said that you don't want that -- instead
> you want to distribute two packages, and not use relative paths.  The
> solution for that is to put the two packages in a place where mzscheme
> will know how to find it with (require (lib ...)) or
> (require (planet ...)).
Indeed.

> But now you say that you don't want to put these in a standard place
> -- you want your users to be able to have one library from a cd and
> one from a usb key.  Fine.  But you don't want to change PLTCOLLECTS,
> and you don't want to use relative (or absolute) paths.  You want the
> code in the collection that is in your usb key to be:
No, here you got me wrong.
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.

It is possible in Java through jars (and classpaths), 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), it's possible with
Perl (again, libraries are first searched on the application
directory, only then on the perl/lib directory... why isn't it
possible with mzscheme?

>  (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>

> But I'm losing track of what you want.  You *want* two collections
> that can be in independent places because "they are different "code
> units"", but you *don't want* two packages for them?
In the midishare / music example, it makes perfect sense to make a
package of only midishare, as it can be used on its own.
It is also used by the music package. But when I give someone the
music package, I don't want to tell him: "here is a music package,
please download also the midishare package". I want to tell him just
"here's a music package, please download this .plt/.zip./whatever
file, it contains everything you need".
I realize this can be done by using relative paths in the music
package, but this seems like a dumb solution -- why should I have to
write (require "../../../../midishare.scm") when I can write (require
(lib "midishare.scm" "midishare")) and not have to count all these ../
everytime?

Also, as I said, the music package also uses the "memoized" package
from planet (Let's say I want to run it also on internet-less
computers). I don't want my user to have to go and download the
memoized package on his own - I want it to be available for him when
he installs my application.

> > > Planet is specifically intended to make downloading code easier.
> > > If the server crashes or dumped, you're stuck in only a slightly
> > > better way than you'd be stuck if plt-scheme is dumped.  So for
> > > maximum robustness, would you also learn how to maintain the C
> > > core and the huge amounts of Scheme code?
> > No. If plt-scheme is dumped, I won't get any updates or bug fixes,
> > but my current code will work with the old binary as expected.
> I did say that you'll be stuck in only a *slightly better* way.
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).

> > If PLaneT dies, my code won't run at all.
> If it's in the cache then it should run.
But it won't be in the cache of a new computer.
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.

> > > But really, how is this different than relying on your OS vendor
> > > for downloading packages?  (Or do you install stuff from CDs and
> > > get nothing else?)  How is this different than CPAN, CTAN, etc,
> > > which rely on repository servers?
> > Not the same at all.
> I can promise you that once I take my wireless card out of this
> laptop, Windows update will not work.
So? Don't use that update. Windows will still work.
> > PLaneT is queried for packages everytime you run an application
> > which requires planet libraries on a new computer. [...]
> I just tried it -- wrote this in a file:
>  (require (planet "memoize.ss" ("dherman" "memoize.plt" 2 0)))
>  (define fib
>    (memo-lambda (n) (if (<= n 1) n (+ (fib (- n 1)) (fib (- n 2))))))
>  (fib 100)
> hit run, and it works.  Then I quit DrScheme, pulled my card out,
> started it again, ran the same code and it runs fine again.
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?


Yoav