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

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

--
http://www.neilvandyke.org/
_________________________________________________
 For list-related administrative tasks:
 http://lists.racket-lang.org/listinfo/users

Reply via email to