Thanks. Are you recommending virtualenv from experience having used it, or from heresay? I would want to know what possible pitfalls and gotchas there might be. Specifically, the description for the package says that it creates "... virtual Python instances, each invokable with its own Python executable. Each instance can have different sets of modules...", but I'm not looking for running two instances with individual custom modules or libraries - I think I'm looking at having two ENTIRE python tool-chains (v2.7 & v2.6). So, I would be asking virtualenv, a python2.7 package itself, to be running an entire python2.6 instance. Would that be in the scope of solution you've suggested?
On 12/29/2014 04:30 PM, Alex Mestiashvili wrote: > On 12/29/2014 09:17 PM, Boruch Baum wrote: >> Hello everyone, >> >> I'm preparing two bug reports, and in trying to sort one of them out, it >> seems that it may be linked to an incompatibility of a script with >> python2.7 (see bug #659831). So, in test that possibility, what I would >> like to do is install some other version of python (I see 2.5 and 2.6 in >> the repositories), in order to see whether the package works with >> another version. >> >> My questions revolve around how time-consuming and worthwhile this >> exercise will be: >> >> 1] Can I have multiple versions of python simultaneously? >> >> 2] Is there a way to specify that one package use a non-default version >> of python? (I don't want to set an old version of python as default, if >> that risks having other packages, depending on 2.7, break). >> >> 3] Is this a quick, straightforward install? Or is it going to be >> something like an emacs install, with all kinds of time-consuming, >> interminable local compilations and configurations? >> >> Please respond to me directly, and on list. Thanks. > > It sounds like you need virtualenv: https://pypi.python.org/pypi/virtualenv > > Regards, > Alex -- hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0
signature.asc
Description: OpenPGP digital signature