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

> > The problem is mostly my ignorance, then. What are .plt files, and how
> > do I use them?
> They are plt-scheme packages, usually containing a collection that can
> be unpacked and installed by users.  They are a basic way of packaging
> up code, which is the functionality that planet builds on.
> mzc can create these .plt packages, see its usage and help desk.
I'll have a look.

> > I have two collections: "midishare" and "music". Code in "music"
> > uses the functionality in "midishare", and it does so with "(require
> > (lib "whatever.scm" "midishare"))". I don't use relative paths for
> > that require, because, well, they are different "code units",
> Why?  Do you plan to distribute them as separate packages?
I don't think so, but I might want to.
I also use the "memoized" package from PLaneT, and would like to
distribute it along with my code as well.

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

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

> > > > > > [...] if I can't control the server, I'm not going to use
> > > > > > it.
> > > > > (That's a very 90's thing to say.)
> > > > Not really, in this case.  I'm not going to distribute software
[...]
> 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. If PLaneT
dies, my code won't run at all.

> 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.
PLaneT is queried for packages everytime you run an application which
requires planet libraries on a new computer. The CPAN modules are
something you (the developer) download once when developing, and can
then distribute with your application.
PLaneT is somewhat more like Sun's applets or WebStart - the
difference is that WebStart applications are hosted on your own
server..

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