-
-
Notifications
You must be signed in to change notification settings - Fork 533
tox should reuse tests_require from setup.py #13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Original comment by @merwok I’m not using setuptools-tests integration at all, so In my current project I’m using extras rather than tests_require, I could look into overriding the install command to run |
Original comment by @brechtm You could run |
Original comment by @bittner @@hpk42 This doesn't mean you want to allow Though, Also, allowing the ini-style sections in |
Original comment by @wosc My vote goes to Donald's suggestion of supporting setuptools extras from tox. |
Original comment by @dstufft 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. |
Original comment by @hpk42 Well, i can imagine two principal solutions to sharing tox and setup.py information:
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. |
Original comment by 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? |
Original comment by @hpk42 sorry, not sure i understand, where would the code accessing "self.distribution.test_require" be located? |
Original comment by @msabramo 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. |
Original comment by @msabramo Oops. Forgot to log in. Would this work?
|
Original comment by @hpk42 Do you know a safe way to fetch test_requires from setup.py? With static metadata that is doable but with an executable file? |
@hpk42 i believe pip does it safely by invoking egg-info with a target directory |
I would tend to close this as wontfix as we have the extras key now as @dstufft suggested. |
I don’t object. I don’t use |
Why not just make the tox config into a python file instead of ini or TOML, then we can define our |
Then you get |
Requirements were specified in both requirements.txt and setup.py: - setup.py should be used, as that's what pip looks at when installing this as a dependency of something else. Test requirements where specified in both test-requirements.txt and setup.py: - test-requirements.txt should be used, as tox cannot cleanly use setup.py for this: tox-dev/tox#13 Change-Id: I0240e16510c2f2cd2c8628aa26c8332f43590faa
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 :)
The text was updated successfully, but these errors were encountered: