[racket-dev] Packaging

From: Sam Tobin-Hochstadt (samth at ccs.neu.edu)
Date: Fri Feb 18 22:54:24 EST 2011

On Fri, Feb 18, 2011 at 8:17 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> One more comment: one of PLaneT's design goals what that if you have a
> working system and you install a new planet package, then you didn't
> break any of the working parts from before. The new system doesn't
> seem to have that as a design goal anymore (I noticed automatic
> upgrades and "freezing" being an explicit operation but there may be
> other places).
>
> Do you have a rationale for deviating from this seemingly nice property?

I think (from my experience working on this problem in the Fortress
context) that this property isn't as nice as it seems to start with.
It has a few important problems:

1. It can't possible be true in general, since two packages or
(especially) two versions of the same package can contend for the same
system resource (a file, a database, a network port, a parameter, a
bit of Racket global state, etc).

2. It's in conflict with two other important goals -- upgrading
packages (to remove bugs, add features, etc) and reducing resource
usage (disk, memory, etc).

3. Often, sharing state in a package/library is very important.  For
example, generative structs have to be generated only once to be
properly shared.  With the planet policy, it's all to easy to install
two packages, both of which require (planet foo/bar), get different
instantiations of foo/bar, and have the two packages be subtly
incompatible (it's even worse when the incompatibility is in some
shared resource other than generative structs, like shared files).
We've had this problem with planet libraries, I believe.

I believe the right solution is to allow individual library authors to
specify that they want the planet policy, or some other policy, to be
applied to particular dependencies, without making it the default.

>
> Robby
>
> On Fri, Feb 18, 2011 at 3:21 PM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
>> You may recall from the meeting over the summer that I promised a
>> packaging Christmas present to Racket. I'm over a month late, but here
>> it is:
>>
>> http://faculty.cs.byu.edu/~jay/tmp/pkgs/spec.html
>>
>> I lay out some goals for the new packaging system and make a concrete proposal.
>>
>> Please share your feedback so I can direct my efforts better.
>>
>> Jay
>>
>> --
>> Jay McCarthy <jay at cs.byu.edu>
>> Assistant Professor / Brigham Young University
>> http://faculty.cs.byu.edu/~jay
>>
>> "The glory of God is Intelligence" - D&C 93
>> _________________________________________________
>>  For list-related administrative tasks:
>>  http://lists.racket-lang.org/listinfo/dev
>>
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/dev



-- 
sam th
samth at ccs.neu.edu



Posted on the dev mailing list.