[Distutils] different python versions in one buildout?!

[Jim Fulton]

On Mon, Aug 30, 2010 at 2:10 PM, Gary Poster <gary.poster at canonical.com> wrote:
>
> On Aug 30, 2010, at 1:27 PM, Jim Fulton wrote:
>
>> On Mon, Aug 30, 2010 at 1:06 PM, Chris Withers <chris at 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.

Now that you mention it, I've used it this way too recently, however
recent turmoil with the Zope test runner make this use case break for
me.  Some subtleties arise from the fact that you can only use one
Python for the recipes and the recipes will sometimes depend in
significant ways on the Python used.

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

This could be done using a files that were extended. It might even be
practical to share a single config and pass overrides to the
sub-buildout.  It's hard to know without trying it. :)

>--and meanwhile, the feature that does exist has suited nicely.

True, however, It has provided faitly painful to maintain, especially
wrt tests.

Jim

--
Jim Fulton