[racket] need to control PLaneT versions

From: Neil Van Dyke (neil at neilvandyke.org)
Date: Tue Aug 23 13:15:04 EDT 2011

PLaneT issue I've mentioned this in the past, and it just bit me again...

For production systems that use PLaneT packages, we need a way for an 
application programmer to control the versions of *all* PLaneT packages 
-- including the ones pulled in indirectly, by dependencies from 
packages that we explicitly "require".  This is in addition to 
mechanisms for authenticating versions and auditing that I've mentioned 

I loaded up some code for a production system into DrScheme 4.2.5 (to 
investigate a possible regression unrelated to PLaneT packages.  I did 
not have PLaneT linkages and caches for 4.2.5 on this machine.  DrScheme 
crunched for 15+ minutes while it was installing a bunch of PlaneT 
packages.  In addition to the PLaneT packages I expected, I noticed it 
started pulling in many packages from the impressive-looking "bzlib/" 
set, which this application does not use explicitly and has not pulled 
in in the past.  (Eventually DrScheme 4.2.5 exhausted all my RAM and was 
thrashing this swap-less system, probably thrashing disk caches in and out.)

Not only are we getting different versions of libraries than we expect, 
but we're pulling in a whole family of packages that we were not when 
this same code was run before.  Even though we are explicitly 
"require"-ing exact versions of all the packages we "require" 
explicitly, if one of those has a non-exact "require" on a second 
package, that can give us a different version, and that different 
version can do whatever it wants, including "require"-ing everything in 
the PLaneT repository or making embarrassing posts from our Facebook 


Posted on the users mailing list.