[plt-scheme] Some more PLaneT questions

Williams, M. Douglas wrote:

> I am ready to release Version 2.0 of the PLT Scheme Science 
> Collection. I have versions for both V209 and V299 (299.100 anyway). 
> The only source code differences are due to changes in contracts – 
> specifically any? -> any/c and natural? -> natural/c.
>
> 1) Should I release both versions to PLaneT as they are or should I 
> attempt to make the source the same for both?
>
Yes, release both. Even if you made the source code identical for both, 
PLaneT can't take advantage of that anyway.

> 2) The graphics functionality for the science collection requires a 
> patch to fix a bug in the plot collection (PLoT) for Version 299.100. 
> Should I include the patched file from PLoT (plplot.ss)? Is there a 
> better way to handle this?
>
I think probably the right way to handle this is to get the PLoTters to 
apply the bug fix to the main distribution and release the package 
without it.

> I am also ready to release Version 0.9 of the PLT Scheme Simulation 
> Collection. The simulation collection makes use of the science 
> collection internally. During development, I have each of these 
> collections in a local collects directory and use (require (lib <file> 
> “science”)), for example, when I need <file> from the science 
> collection. This means that when I’m ready to release it, I have to 
> change all of the require calls throughout the collection to refer to 
> PLaneT.
>
> 3) Is there a better process for developing collections that are going 
> to be released to PLaneT? For example, can I put them in the local 
> planet cache (or at least I think of it as a cache) manually? Will 
> this interfere with the normal workings of PLaneT? Is that what I 
> should have been doing all along?
>
Yes you can; there is now a PLaneT package development commandline tool 
called `planet' that will allow you to manipulate your local PLaneT 
cache (among other things it does). Do `planet -h' for a quick help 
summary of the tool's features, but the one you want is:

-f <plt-file> <owner> <maj> <min>, --file <plt-file> <owner> <maj> <min> :

Install local file <plt-file> as though it had been downloaded from the 
planet server. The installed package has path

(planet (<owner> <plt-file's filename> <maj> <min>))

If you're developing interrelated planet packages, I recommend that you 
inject them into your planet cache but that you do not put them in a 
collection accessible to (lib ...); there have been many many minor 
revisions released due to people accidentally leaving those (lib ...) 
references in their code, which of course won't work on anyone else's 
computer. Also, as a rule of thumb: within a package, require other 
pieces of the same package using filename only; e.g.

(require "private/my-internal-code.ss")

Only use the (require (planet ...)) form to require other PLaneT 
packages, but _always_ use that form for that purpose (even in 
development). Only (require (lib ...)) things that are actually part of 
PLT's standard library.

> One last question.
>
> 4) Can I refer to sub-collections using PLaneT? Generally, the entire 
> science collection isn’t needed so it is divided into sub-collections. 
> For example, (require (lib “beta.ss” “science” 
> “random-distributions”)) would just require the beta.ss file instead 
> of all of the random-distributions (or all of the science collection). 
> Is there an equivalent syntax for PLaneT?
>
Pretty much the same way:

(require (planet "beta.ss" ("williams" "science.plt" 1 0) 
"random-distributions")))

Incidentally, this is the reason for those extra parens around the 
package specifier.

-jacob