On Aug 30, 2010, at 1:27 PM, Jim Fulton wrote: > On Mon, Aug 30, 2010 at 1:06 PM, Chris Withers <ch...@simplistix.co.uk> wrote: >> Gary Poster wrote: >>>> >>>> It's not like I want my system matplotlib in one part and a locally >>>> failing-horribly buildout-installed matplotlib in another part. >>> >>> No, but single buildouts are used to install different sections with >>> entirely different requirements, including different Python versions. >> >> This feels like needless complexity to me. > > This is a requirement we had here at ZC. It wasn't > needless. > >> If a different python is needed, it should be in its own buildout. >> If you need to bundle a bunch of buildouts together because of this, use a >> recipe that runs "sub buildouts" in a separate process... > > It's possible that this would be a better approach. It's true that > supporting multiple Python interpreters is a pain. I don't have this > need atm, so I'm not motivated to try your solution. :) > > I wonder what other people think. Does anyone else have current > need to deal with multiple Python versions in the same buildout?
Launchpad has needed to when we needed to generate scripts that were only supported by Python version X but Launchpad only supported version Y. This was typically in transition periods, so the feature was very nice--we would be switching back to a uniform Python soon, but meanwhile, the buildout and its components still worked. That kind of thing is generally my most compelling usage. I've also used it (or seen it used? I forget) to set up multiple test runners for different Python versions, for library packages. That's convenient sometimes. I could imagine these being done in a way as Chris described it, but to be convenient I'd want to share configuration across the buildouts--and meanwhile, the feature that does exist has suited nicely. Gary _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
