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

Hi -- I'm just now catching up on this discussion, so this is sort of
an omnibus reply to the main points of the thread to this point.

Pupeno wrote:

 > I don't want drscheme to download anything, I want to download them
 > myself and install it. Furthermore, I want to read the source code.

The `planet' commandline tool will allow you to download a package
from PLaneT without installing it or to install a package without
downloading it. The source code will be in

  $ADDONS/planet/300/cache/$user/$pkg-name/$maj/$min,

where $ADDONS is your addons directory, and $user, $pkg-name, $maj and
$min are the appropriate values for the particular package.

If you use DrScheme, you can more easily jump to the source using
DrScheme's usual methods: the module browser [View -> Open Module
Browser], or right-clicking the appropriate (require (planet ...))
line and selecting "Open <filename>".

There is one wrinkle in that there's no way, from the planet tool, to
just *unpack* a .plt file without installing (= compiling) it at the
moment, and since we're talking about Scheme, compilation really
means evaluation. Of course the planet client unpacks and then
installs internally; I'll expose the unpacking functionality directly
in the tool as soon as I get a chance.

And of course, if you really don't want PLaneT to distribute your
packages and you'd like them distributed some other way, you can
either use .plt files or make up an entirely different system with
.tar.gz files or something else of your own device. Installing scheme
code so that mzscheme treats it as a library isn't rocket science --
just stick it in either $PLTCOLLECTS/<library-name>/ or
$ADDONS/$VERSION/collects/<library-name>/ and you're set, where
$VERSION is the output of `mzscheme -mve '(display (version))'`.

Yoav Goldberg wrote:

 >  so I think writing and distributing a small script that will
 > connect to PLaneT, download the package you want and install it as a
 > collect, would be extremely usefull (I would do it myself if any of
 > you redirect me to some documentation on the inside of the planet
 > system).

The planet commandline tool does these things.

 > I think PLaneT is extremly cool, and could be very usefull when
 > developing code, but just not reliable enough inorder to distribute
 > code that requires direcly from it

It's true, the PLaneT server has had a few annoying stability problems
--- mostly due to its phenomenal ability to *only* and *always*
mysteriously stop working when I'm at a conference ... :(

[in another message:]

 > [Yoav wants to] install [a bundle of code] as a collection in a way
 > typical users could find it, and from then on require it with "lib".

The tools that come with the PLT distribution can't do that by
default, since schools and system administrators often install the PLT
software tree in a place where normal users don't have write
access. [And PLaneT can't do it for other reasons as well.]

Now, it's possible to make a .plt file that does whatever you'd like,
if you're willing to read about the format of .plt files (search for
.plt in the Help Desk), so if you want to use .plts you can.

Pupeno wrote:

 > I also use the "memoized" package from PLaneT, and would like to
 > distribute it along with my code as well.

In general I agree that it would be nice to have some sort of
crystallized distribution file that would contain your code and all
the planet modules someone might need to run it, so that people
without network access could use your code directly. It also should
not be necessary to break the planet link to do that, since having
those planet links there gives you benefits (easy upgrading when a
bugfix is published for a library you use, etc). I've known about this
for a while but haven't had the time to program up an acceptable
solution yet.

Noel Welsh wrote:

 > Some points:

 > The programmer has to decide at coding time to use libraries via
 > Planet or .plts.

Just because I'm pedantic like that, I should point out that PLaneT
and .plts are not competing systems; PLaneT is an automatic mechanism
for distributing and installing .plts. So the issue is really between
installing .plts from PLaneT or installing them manually.

 > So I suggest:

 > - remove the distinction between (require (lib ...)) and (require
 > (planet ...)) (Yay, less typing)

Hm ... I'm not sure what you mean here. The distinction between those
two forms isn't very easy to remove, and if it were it would
necessarily involve making library requires bigger rather than making
planet requires smaller. The only extra information the planet require
form has over the lib require form is basically a little more
structure in the name of the library -- "reduction-semantics" versus
("robby" "reduction-semantics" 1 0). I don't see how to get rid of
any of those three extra pieces in general.

 > - .plts should be encode their version number and path, so one .plt
 > can be released as both a file for download, and a Planet package.
 > I.e. a .plt contains all the necessary information for PLT Scheme to
 > figure out where it should be installed and act as if it was
 > downloaded from Planet

I have considered this and I'm willing to be swayed, but I decided
against it originally because I didn't want to have to trust planet
package authors to give semantically-correct package numbers to their
packages -- experience has shown me that my distrust was probably
wise. It's probably possible to make the packaging tool call out to
planet to retrieve a package number automatically, but at the moment
the planet server makes that difficult. (The planet server needs
revision anyway, though, so maybe that feature would be useful.)

To be clear, the only advantage I see users getting out of this change
would be the ability to say "planet -f package" rather than "planet -f
package name maj min". Do you have some other angle in mind?

 > - Planet should provide a way to download .plts via, say, a web
 > browser, so people can create their own private repositories

This is possible already with the planet command-line tool.

 > - Implement a fault tolerant (i.e. distributed) Planet.

 > I feel the last should be undertaken by those who have expressed a
 > desire for such a thing -- it would be quite some work.

Agreed. Though I do like the way that a lot of linux distributions
work, where there's an "official" repository but there's no problem if
you want to set up your own secondary repository and use that as an
extra source of packages.

-jacob