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

On Oct 25, Yoav Goldberg wrote:
> > If you do, then put them in your addons directory, and you can
> > still use that.  To see where that is, run this:
> >  (build-path (find-system-path 'addon-dir) (version) "collects")
> But I want to put them in my APPLICATION directory. I want to be
> able to download a zip file (or an installer), unpack all the files
> (and all the non-standard dependencies) to that directory, and let
> it run, and knowing that if I copy that directory all of this
> software is copied, and if I delete that directory then ALL of the
> software is gone, without leaving traces on my computer. I want to
> make it work from a DiskOnKey. I want to run in on a non-networked
> computer. There are tons of reasons.

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

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:

  (module foo mzscheme
    (require (lib "blah.ss" "blah"))
    ...)

how exactly should mzscheme know that "blah" is in your cd drive?


> > Otherwise (and assuming you don't want to write your own code
> > distribution system), you will just have to tell people to
> > download and install both .plts to make things work.
> Why can't they just download and install ONE .plt file, with both
> collections (as well as all the other non-standard collections I'm
> using)?

That's possible.  You will need to read more to do it though.

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?


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


> If PLaneT dies, my code won't run at all.

If it's in the cache then it should run.


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


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

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                  http://www.barzilay.org/                 Maze is Life!