multi-version parallel-installed modules
Is there any proposal to accommodate having parallel-installed multiple versions of modules? I have client code in multiple projects using version x.y of a C-compiled module A. I want to test a new version x.z of module A, but all client software needs to be recompiled against the new version. If I just install the module, all the other client software breaks. I know I could test using virtualenv, but there would be a lot of modules to install into virtualenv to run the tests, so this would be cumbersome. I'd prefer to have multiple version co-exist so I could update projects to the new version at my convenience. How does this situation happen? I have lots of c++ code using pyublas, which allows c++ code written to the boost::ublas interface to operate on numpy vectors/matrixes. pyublas is built against boost libs. pyublas installs a module, whose purpose is to register conversions. When I update boost libs, I have to rebuild pyublas and install the updated module. Then rebuild my client software modules. If pyublas is built against a different boost version than my client modules, the conversions will fail.
On 18/08/2010 15:34, Neal Becker wrote:
Is there any proposal to accommodate having parallel-installed multiple versions of modules?
I have client code in multiple projects using version x.y of a C-compiled module A.
I want to test a new version x.z of module A, but all client software needs to be recompiled against the new version. If I just install the module, all the other client software breaks.
I know I could test using virtualenv, but there would be a lot of modules to install into virtualenv to run the tests, so this would be cumbersome. I'd prefer to have multiple version co-exist so I could update projects to the new version at my convenience.
How does this situation happen? I have lots of c++ code using pyublas, which allows c++ code written to the boost::ublas interface to operate on numpy vectors/matrixes. pyublas is built against boost libs. pyublas installs a module, whose purpose is to register conversions.
When I update boost libs, I have to rebuild pyublas and install the updated module. Then rebuild my client software modules. If pyublas is built against a different boost version than my client modules, the conversions will fail.
I believe that setuptools / distribute already has a mechanism for supporting this. It basically does it with sys.path hackery. As far as I know there are no plans to include this in distutils2 - but Tarek can correct me if I am wrong. All the best, Michael Foord
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
Michael Foord wrote:
On 18/08/2010 15:34, Neal Becker wrote:
Is there any proposal to accommodate having parallel-installed multiple versions of modules?
You can easily implement such a setup by placing the module versions into a separate dir and then adding the right version dir to you sys.path before test startup. E.g. export PYTHONPATH=mymodule/3.0; python test.py export PYTHONPATH=mymodule/3.1; python test.py
I have client code in multiple projects using version x.y of a C-compiled module A.
I want to test a new version x.z of module A, but all client software needs to be recompiled against the new version. If I just install the module, all the other client software breaks.
I know I could test using virtualenv, but there would be a lot of modules to install into virtualenv to run the tests, so this would be cumbersome. I'd prefer to have multiple version co-exist so I could update projects to the new version at my convenience.
How does this situation happen? I have lots of c++ code using pyublas, which allows c++ code written to the boost::ublas interface to operate on numpy vectors/matrixes. pyublas is built against boost libs. pyublas installs a module, whose purpose is to register conversions.
When I update boost libs, I have to rebuild pyublas and install the updated module. Then rebuild my client software modules. If pyublas is built against a different boost version than my client modules, the conversions will fail.
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 18 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
participants (3)
-
M.-A. Lemburg -
Michael Foord -
Neal Becker