1. Holger Krekel
  2. tox
  3. Issues


Issue #13 on hold

tox should reuse tests_require

Éric Araujo
created an issue

First, thanks for tox. It is very useful.

I have a setuptools-based setup.py with install_requires, setup_requires and tests_require. I was surprised to find that I needed to duplicate the test dependencies in tox.ini; I checked the doc and many examples from projects I follow and finally asked for confirmation on IRC. Ronny suggested that I report this.

IMO, tox should fetch setup_requires and tests_require dependencies too. This would certainly shorten a lot of people’s tox.ini :)

Comments (15)

  1. Anonymous

    Would this work:

            if self.distribution.tests_require:
  2. Marc Abramowitz

    I haven't looked at the code for tox, but maybe it could be done in a way such that Tox only installs the test_requires dependencies of the package being tested and not the dependencies of the dependencies. That seems pretty safe in that a person running tox on their own package should be comfortable with whatever it does.

  3. sashahart

    I'd love to see this fixed in tox. The problem is just getting data out of setup.py. Running setup.py in order to introspect the module or parsing setup.py into an AST seem crazy. Depending on setuptools seems strange at this late date, too. Wouldn't this be better fixed by exposing data in a way which doesn't require running setup.py again, say from the side of distutils2?

  4. Holger Krekel repo owner

    Well, i can imagine two principal solutions to sharing tox and setup.py information:

    • generating setup.py from tox information
    • execute setup.py in a monkeypatching way so that we can find out what test_requires etc. it sets (if any).

    In both cases, tox needs to become more explicit about the packaging step (currently it's unconditionally performing sdist-packaging). Personally, i am rather interested in generating setup.py (and later pep426 compliant setup.cfg etc.) from tox.ini, so that trove-classifiers, supported platforms, dependencies, become test-verified information and are kept in a non-redundant manner.

  5. Donald Stufft

    An alternative way of doing this, is for tox to support adding an extra to the install command. This way extras_requires could be used and tox won't have to "reach into" the setup.py, it would just add some extra stuff to the command to install the package.

  6. Peter Bittner

    @Holger Krekel This doesn't mean you want to allow setup.cfg as an alternative configuration file, does it? I would love to see this in fact.

    Though, tox.ini being the default is rather elegantly solved at config.py, line 269+. I don't see how to fix this without adding at least about 10 lines of code. scream Any ideas?

    Also, allowing the ini-style sections in setup.py would probably have to entail some design decisions: It could make sense to prefix the sections names with tox: or so, e.g. [tox:testenv] instead of [testenv] in the basic example in the docs. You probably have this envisioned before.

  7. Éric Araujo reporter

    I’m not using setuptools-tests integration at all, so setup.py test would not work. I prefer to tell tox how to run pytest, rather than having a setuptools test command between them.

    In my current project I’m using extras rather than tests_require, I could look into overriding the install command to run pip install .[test] and solve my issue.

  8. Log in to comment