
Hi all, I've just published few python rpms for the trunk source. You can download and install the packages from (either by hand or using yum/yast): http://download.opensuse.org/repositories/home:/cavallo71:/opt-python- interpreters/ The interpreters will install under so it will leave the system python untouched: /opt/opt-python-svnXXXXX-2.7a0 XXXXX is the svn revision. Once installed you can use them just sourcing the file: $> . /opt/opt-python-svnXXXXX-2.7a0/opt-python-svnXXXXX-env.sh $> python Python 2.7a0 (trunk, May 24 2009, 21:18:39) [GCC 4.3.2 [gcc-4_3-branch revision 141291]] on linux2 Type "help", "copyright", "credits" or "license" for more information. There is a web page containing the build results (including a small simple smoke test): http://pyvm.sourceforge.net/ Module developer can use these build to test against the more up to date python source and anticipating bugs. Developer can use it to run regression/integration tests. I hope that will help, Regards, Antonio

A. Cavallo wrote:
Hi all,
I've just published few python rpms for the trunk source. You can download and install the packages from (either by hand or using yum/yast):
Module developer can use these build to test against the more up to date python source and anticipating bugs. Developer can use it to run regression/integration tests.
Thanks Antonio. Having RPMs for the trunk is useful. It is not well known but you can also build custom versions of Python using zc.buildout, which can be run with the system version of Python but use a different Python version inside for any or all of the parts. My system Python is 2.5 but here is a buildout I use to test stuff with 2.4. The magic is the python= assignment in the [buildout] section which sets globally the executable to use for all parts which do not specify their onw python= in their part definition. The other magic is the executable= assignment in the part that creates an instance of the Python interpreter. It points to the actual executable binary. Using this you can create one buildout with a handful of Python versions and run your module test suites against all of them. --- cut here --- [buildout] python = Python-2.4.3 parts = Python-2.4.3 pyprompt-2.4 [Python-2.4.3] recipe = zc.recipe.cmmi url = http://www.python.org/ftp/python/2.4.3/Python-2.4.3.tgz extra_options = --prefix ${buildout:parts-directory}/python243 --enable-unicode=ucs2 executable = ${buildout:parts-directory}/python243/bin/python [pyprompt-2.4] recipe = zc.recipe.egg:scripts interpreter = python2.4 eggs = extra-paths = # example of setting up yet another prompt [pyprompt-2.6] recipe = zc.recipe.egg:scripts interpreter = python2.6 python = Python-2.6.2 eggs = extra-paths = --- cut here ---

Hi, the scope for these svn builds is slightly different. Firstly they are done on a xen virtual machine: this means they are rebuilt as in a "fresh" standard distro install. Buldbot don't do that, normally, so there's no guarantee libraries present on the buildbot host are going to be binary compatible with the one installed on the destination machine (yes people do tamper their build systems). Secondly they're mean to be "easily" deployable: in fact the opensuse build server provides the yum/yast hosting as well. In business time is money but for an opensource/freeware developer time is life and, as humble contributor, I don't want to waste my time on playing the rebuilding game. I hope to save this time to other as well making possible for everyone to focus more on the important things (in life and development). (IMHO This is one of the main reasons for the never ending "The year of linux on the desktop" joke). Thirdly they're provided with a (simple) smoke test: it will check if the binary provides at least a minimum set of modules. Fourth they're drop in package and won't interfere with normal system administration (a fourth important point in my opinion): they can be installed side by side with each other and with the system python. Fifth they use the latest version of the svn python and they can be rebuild for any upcoming revision as well. Sixth sorry for this very long mail, Regards, Antonio
Thanks Antonio. Having RPMs for the trunk is useful.
It is not well known but you can also build custom versions of Python using zc.buildout, which can be run with the system version of Python but use a different Python version inside for any or all of the parts.
My system Python is 2.5 but here is a buildout I use to test stuff with 2.4.
participants (2)
-
A. Cavallo
-
Jeff Rush