[Python-Dev] 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. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multi-version parallel-installed modules
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] multi-version parallel-installed modules
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/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r84166 - python/branches/py3k/Misc/developers.txt
On Tue, Aug 17, 2010 at 7:00 PM, Benjamin Peterson wrote: > 2010/8/17 martin.v.loewis : >> Author: martin.v.loewis >> Date: Wed Aug 18 00:58:42 2010 >> New Revision: 84166 >> >> Log: >> Add Ask Solem. >> >> >> Modified: >> python/branches/py3k/Misc/developers.txt >> >> Modified: python/branches/py3k/Misc/developers.txt >> == >> --- python/branches/py3k/Misc/developers.txt (original) >> +++ python/branches/py3k/Misc/developers.txt Wed Aug 18 00:58:42 2010 >> @@ -20,6 +20,10 @@ >> Permissions History >> --- >> >> +- Ask Solem was given commit access on Aug 17 2010 by MvL, >> + on recommendation by Jesse Noller, for work on the subprocess >> + library. > > IIRC it was multiprocessing. > > > > -- > Regards, > Benjamin Benjamin's correct ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Fwd: Old link text in documentation
Could (and should) the online Python 3.1 docs be updated to show Python 2.7 as stable? All the best, Michael Original Message Subject:Old link text in documentation Date: Sun, 15 Aug 2010 15:49:34 -0700 From: Aaron DeVore To: [email protected] The link text at http://docs.python.org/py3k/ under "Docs for other versions" still describes 2.7 as being "in development" -Aaron DeVore ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Old link text in documentation
Am 18.08.2010 17:11, schrieb Michael Foord: > Could (and should) the online Python 3.1 docs be updated to show Python > 2.7 as stable? I think the answer is "no, it could not". How many old documentation sets would you want to go through, and regenerate them? There is also http://docs.python.org/release/2.6.5/ http://docs.python.org/release/2.6.4/ http://docs.python.org/release/2.6.3/ etc. In particular, http://docs.python.org/release/2.6.2/ still lists 3.1 as in-development. If that would be fixed, I think the fix should work for all documentation sets, and such a fix might be difficult to implement. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Old link text in documentation
On 18/08/2010 21:59, "Martin v. Löwis" wrote: Am 18.08.2010 17:11, schrieb Michael Foord: Could (and should) the online Python 3.1 docs be updated to show Python 2.7 as stable? I think the answer is "no, it could not". How many old documentation sets would you want to go through, and regenerate them? There is also http://docs.python.org/release/2.6.5/ http://docs.python.org/release/2.6.4/ http://docs.python.org/release/2.6.3/ etc. In particular, http://docs.python.org/release/2.6.2/ still lists 3.1 as in-development. If that would be fixed, I think the fix should work for all documentation sets, and such a fix might be difficult to implement. Ok, fair enough. Michael Regards, Martin -- http://www.ironpythoninaction.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Old link text in documentation
Am 18.08.2010 20:59, schrieb "Martin v. Löwis": > Am 18.08.2010 17:11, schrieb Michael Foord: >> Could (and should) the online Python 3.1 docs be updated to show Python >> 2.7 as stable? > > I think the answer is "no, it could not". > > How many old documentation sets would you want to go through, and > regenerate them? There is also > > http://docs.python.org/release/2.6.5/ > http://docs.python.org/release/2.6.4/ > http://docs.python.org/release/2.6.3/ > > etc. > > In particular, > > http://docs.python.org/release/2.6.2/ > > still lists 3.1 as in-development. > > If that would be fixed, I think the fix should work for all > documentation sets, and such a fix might be difficult to implement. Actually, the ones referred to here are the continually updated docs from the branch head, which I just fixed to show the correct information. I agree about the doc sets specific to releases. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
