tox should reuse tests_require

Issue #13 on hold
Éric Araujo created an issue

First, thanks for tox. It is very useful.

I have a setuptools-based 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. Holger Krekel repo owner

    Do you know a safe way to fetch test_requires from With static metadata that is doable but with an executable file?

  2. Former user Account Deleted

    Would this work:

            if self.distribution.tests_require:
  3. Marc Abramowitz

    Oops. Forgot to log in.

    Would this work?

            if self.distribution.tests_require:
  4. 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.

  5. Holger Krekel repo owner

    sorry, not sure i understand, where would the code accessing "self.distribution.test_require" be located?

  6. Sasha Hart

    I'd love to see this fixed in tox. The problem is just getting data out of Running in order to introspect the module or parsing 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 again, say from the side of distutils2?

  7. Holger Krekel repo owner

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

    • generating from tox information
    • execute 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 (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.

  8. 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, it would just add some extra stuff to the command to install the package.

  9. Peter Bittner

    @@hpk42 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, line 269+. I don't see how to fix this without adding at least about 10 lines of code. 😱 Any ideas?

    Also, allowing the ini-style sections in 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.

  10. Éric Araujo reporter

    I’m not using setuptools-tests integration at all, so 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.

  11. Log in to comment