The subvertpy ebuild unconditionally removes the subvertpy.tests package. As a result of this, the bzr selftest command will exit with an error message: $ bzr selftest --list-only bzr: ERROR: No module named tests You may need to install this Python library separately. $ bzr -Derror selftest --list-only 2>&1 | tail -n3 File "/usr/lib64/python2.7/site-packages/bzrlib/plugins/svn/tests/__init__.py", line 20, in <module> import subvertpy.tests ImportError: No module named tests Not even the "test" USE flag will help. There should at least be some use flag to enable those tests to be installed as well. Otherwise the bzr-svn test suite should be removed, too. And in an ideal world, both would be possible, controlled by USE flags, and the bzr-svn test suite would depend on the subvertpy tests being installed. As a workaround for running the bzr test suite, one can disable the svn plugin: $ BZR_DISABLE_PLUGINS=svn bzr selftest ...
Hm. It is common practice to not install test packages into site-packages. Haven't looked at the bzr-svn ebuild, but I think the problem (and solution) should be contained in there.
Is that "common practice" deliberatly applied to testing code that other packages might depend on, or is it more likely intended for unit tests aimed at a single package only? Test dependencies would likely break FEATURES=test as well. If this is so common, shouldn't there be an eclass function to do the python_execute_function function? If you were to introduce such a function, you could combine that change with the introduction of a suitable keyword. So e.g. subvertpy would simply export a variable DELETABLE_TESTS="subvertpy/tests", and the eclass would add all the rest. One reason for the introduction of a USE flag which prevents deletion of the tests: the upstream installes do install these tests as part of their normal procedure. So any package which depends on one of the affected packages might have a right to expect the tests to be present. This also includes packages not in portage. therefore there should be a way to install a package with all the stuff its installer does install, imho. A quick grep indicates that this should probably affect the following packages as well, according to a quick grep: dev-python/4suite dev-python/astng dev-python/bsddb3 dev-python/cherrypy dev-python/cssutils dev-python/docutils dev-python/dulwich dev-python/fudge dev-python/functest dev-python/graphy dev-python/logilab-common dev-python/martian dev-python/mygpoclient dev-python/oauth2 dev-python/pygame dev-python/pygraphviz dev-python/pylint dev-python/pyopenssl dev-python/pysqlite dev-python/simplejson dev-python/stomper Do you want me to file a separate bug requesting the USE flag, so this one here can concentrate on the problem with subvertpy and bzr-svn?
(In reply to comment #2) > Is that "common practice" deliberatly applied to testing code that other > packages might depend on, or is it more likely intended for unit tests aimed at > a single package only? Test dependencies would likely break FEATURES=test as > well. These are my own words and not the word of Gentoo. They aren't found in the python developers guide, it's just something that I've seen being applied to lots of packages. > > If this is so common, shouldn't there be an eclass function to do the > python_execute_function function? If you were to introduce such a function, you > could combine that change with the introduction of a suitable keyword. So e.g. > subvertpy would simply export a variable DELETABLE_TESTS="subvertpy/tests", and > the eclass would add all the rest. This is actually a good question and should be answered either programmatically or by docs. Lets first get a python@ developers view on this before filing a bug. > > One reason for the introduction of a USE flag which prevents deletion of the > tests: the upstream installes do install these tests as part of their normal > procedure. So any package which depends on one of the affected packages might > have a right to expect the tests to be present. This also includes packages not > in portage. therefore there should be a way to install a package with all the > stuff its installer does install, imho. I think USE=test should suffice for such a thing. What we need to do then is start installing these - but it also raises a couple of questions: - What do we do for packages where tests isn't a package ( packages = ['foo', 'foo.bar'] ) - Where do we install tests so they're equally accessible disregarding package > > A quick grep indicates that this should probably affect the following packages > as well, according to a quick grep: > dev-python/4suite > dev-python/astng > dev-python/bsddb3 > dev-python/cherrypy > dev-python/cssutils > dev-python/docutils > dev-python/dulwich > dev-python/fudge > dev-python/functest > dev-python/graphy > dev-python/logilab-common > dev-python/martian > dev-python/mygpoclient > dev-python/oauth2 > dev-python/pygame > dev-python/pygraphviz > dev-python/pylint > dev-python/pyopenssl > dev-python/pysqlite > dev-python/simplejson > dev-python/stomper What we should do is go through every packages setup.py and see if it is in their packages ( for instance https://github.com/simplejson/simplejson/blob/master/setup.py#L85 ). > > Do you want me to file a separate bug requesting the USE flag, so this one here > can concentrate on the problem with subvertpy and bzr-svn? Well, we should stick to solving bzr-svn tests here - but I'd still like to hear from a -dev regarding tests first.
Keeping subvertpy's tests around is the simplest solution. Changing bzr-svn's test suite to operate independently is a job for upstream. +*subvertpy-0.8.5-r1 (07 Sep 2011) + + 07 Sep 2011; Mike Gilbert <floppym@gentoo.org> +subvertpy-0.8.5-r1.ebuild: + Don't remove tests: this breaks bzr selftest. Bug 382051 by Martin von + Gagern. +
Probably only subvertpy/tests/__init__.py is needed and subvertpy/tests/test_*.py could be deleted.
