Page MenuHomeSoftware Heritage

swh-vault's unit tests are broken on jenkins
Closed, MigratedEdits Locked

Description

with eg.

_______________ ERROR collecting swh/vault/tests/test_backend.py _______________
ImportError while importing test module '/home/jenkins/workspace/DVAU/tests/swh/vault/tests/test_backend.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
swh/vault/tests/test_backend.py:14: in <module>
    from swh.vault.tests.vault_testing import VaultTestFixture, hash_content
swh/vault/tests/vault_testing.py:12: in <module>
    from swh.storage.tests.storage_testing import StorageTestFixture
.tox/py3/lib/python3.5/site-packages/swh/storage/tests/__init__.py:9: in <module>
    from hypothesis.strategies import (binary, composite, sets)
E   ImportError: No module named 'hypothesis'

So the question is now: should hypothesis be in storage's requirements.txt instead of requirements-tests.txt?

Event Timeline

douardda created this task.

Hypothesis is a test requirements from storage.
The vault uses the storage's fixture (which now requires as test hypothesis but not for everything)
Hypothesis is not used by the vault so that fails here.

So i see 3 solutions:

  1. move the data generation to another module (as this won't be transitively required by the vault, that won't break) -> seems the right call as this does not need to be opened if not needed
  2. add the hypothesis in the vault's requirements-test.txt -> that's a workaround that won't impede that pattern to be reproduced elsewhere
  3. add hypothesis in the storage's requirements (as you proposed) -> That could solve the problem and not draw the caveat of 2. I'm not sure whether the data generation should say in the storage though... (but yagni for now ;) That data is representing our model, so it could be either in the model or in the core (centralized test fixtures are usually there)...

I think the more reasonable approach for now is 1 and won't impede 3 to be done if that needs to.

What do you think?

Or a fourth solution:

  1. make the setup add all [testing] version of swh.* dependency, something like:
diff --git a/setup.py b/setup.py
index 7efe02b..e62be82 100755
--- a/setup.py
+++ b/setup.py
@@ -8,6 +8,8 @@ from setuptools import setup, find_packages
 
 from os import path
 from io import open
+import re
+
 
 here = path.abspath(path.dirname(__file__))
 
@@ -16,7 +18,7 @@ with open(path.join(here, 'README.md'), encoding='utf-8') as f:
     long_description = f.read()
 
 
-def parse_requirements(name=None):
+def parse_requirements(name=None, env=None):
     if name:
         reqf = 'requirements-%s.txt' % name
     else:
@@ -31,6 +33,9 @@ def parse_requirements(name=None):
             line = line.strip()
             if not line or line.startswith('#'):
                 continue
+            if env is not None:
+                line = re.sub(r'^([^ <>=!]+)(.*)$',
+                              r'\1[{}]\2'.format(env), line)
             requirements.append(line)
     return requirements
 
@@ -46,7 +51,8 @@ setup(
     packages=find_packages(),
     install_requires=parse_requirements() + parse_requirements('swh'),
     setup_requires=['vcversioner'],
-    extras_require={'testing': parse_requirements('test')},
+    extras_require={'testing': (parse_requirements('test') +
+                                parse_requirements('swh', env='testing'))},
     vcversioner={},
     include_package_data=True,
     zip_safe=False,

The commit mentioned should fix it.
In the current state though, for the build to be green again, that'd need another swh-storage tag (and publish to pypi though).

In the current state though, for the build to be green again, that'd need another swh-storage tag (and publish to pypi though).

Indeed (after some jenkins massaging, which needed some fix in the publish step). It's green again [1]

[1] https://jenkins.softwareheritage.org/view/swh%20dashboard/job/DVAU/job/tests/20/