Hi, I am the python-unit maintainer (upstream program called PyUnit) for python 1.5 and 2.0. PyUnit has been included in Python 2.1. but I won't give it away since it does evolve separately from Python releases.
However, because of PYTHONPATH, the latest version of the module will never be loaded by the interpreter. In 2.0 (and quite the same in 2.1), PYTHONPATH looks like: amboise:~$ python2 -c 'import sys; print sys.path' ['', '/usr/lib/python2.0', '/usr/lib/python2.0/plat-linux2', '/usr/lib/python2.0/lib-dynload', '/usr/local/lib/python2.0/site-packages', '/usr/local/lib/site-python', '/usr/lib/python2.0/site-packages', '/usr/lib/site-python'] So, if the interpreter find the module in its core modules, it will never see that a newer version of the module was installed in site-packages. Usually, packages installed separately (site-packages) from the core python modules are more recent that the same modules of the core, because they evolve faster than python releases. Manual installations of modules (/usr/local) are usually done when packages are not up-to-date, so more recent than site modules. This is a well known problem since python-xml (PyXML) is both in 2.0 core and in a separate package and PyXML people have implemented an ugly hack to work this around. So, I'm proposition to reorganize the PYTHONPATH like this : ['', '/usr/local/lib/python2.0/site-packages', '/usr/local/lib/site-python', '/usr/lib/site-python' '/usr/lib/python2.0/site-packages', '/usr/lib/python2.0', '/usr/lib/python2.0/plat-linux2', '/usr/lib/python2.0/lib-dynload', ] I know that it could lead to some problems but not that much I think. Thanks in advance for your comments. PS: it would be usefull to talk to Brendan O'Dea who chose the same ordering for Perl packages. -- Jérôme Marant <[EMAIL PROTECTED]>
