setup.py test as test entry point. #8135
Conversation
|
Looks cool. The main reason we removed support for |
|
Yes, I explicitly do no want to use |
|
👍 to |
|
The test failure is actually spurious (well, I didn't touch the command run by travis). I think the first actionable items are
|
|
TBH, I don't see the point in keeping either of those. We've fixed the warnings and they aren't visible anyway (need to install pytest-warnings to show them at the end of the test run; maybe should add that to docs). The recursion limit thing is something that hasn't been triggered on CI yet. |
1759c5a to
aa209ff
Compare
|
I moved the At that point (if this works for other people too) I think we need to decide whether to push this forward as the preferred entry point, and, if so, write the relevant documentation and update the CI scripts (although there's probably some value to keep at least one CI instance to test that the installed version works too). |
|
Fixes #2175. |
This is a proof of concept that `python setup.py test` can be used as
entry point to the test suite.
`python setup.py test` will build matplotlib and run `pytest` locally.
There is no need to install matplotlib in a venv, `setup.py test`
apparently handles `PYTHONPATH` itself (and even the `mpl_toolkits`
namespace package seems to be handled properly). (In my opinion, this
is an unexpected big plus.)
The `test` section of `setup.cfg` had to be renamed to `test_build` as
it is otherwise interpreted as an option passed to `setup.py test`,
which it is not, right now. It may be advantageous to make
setup.py test --local-freetype=true
"work", but this would require more refactoring as `setupext` is
currently imported, and thus the choice of whether to use a local
freetype done, at the top of `setup.py`, before we know whether we are
going to run the test suite. This needs to be
documented.
Arguments to `pytest` are passed as
python setup.py test -a "$PYTEST_ARGS"
(as `setup.py` will swallow unspecified arguments itself).
The remaining setups in `tests.py` are setting the recursion limit and
turning on some deprecation warnings. I think the former can be
implemented as a local pytest plugin, and the latter as a session-scoped
fixture.
If we switch to this method, the CI scripts would need to be adjusted as
well.
The implementation is essentially copy-pasted from
http://doc.pytest.org/en/latest/goodpractices.html#manual-integration.
If we did not overrider install_dists, setup.py test would install dependencies using easy_install, which we definitely do not want.
16f036e to
86dc98d
Compare
|
Closing as I think that the general python ecosystem is moving towards tox for this kind of things, but we can always reopen if needed... |
This is a proof of concept that
python setup.py testcan be used asentry point to the test suite.
python setup.py testwill build matplotlib and runpytestlocally.There is no need to install matplotlib in a venv,
setup.py testapparently handles
PYTHONPATHitself (and even thempl_toolkitsnamespace package seems to be handled properly). (In my opinion, this
is an unexpected big plus.)
The
testsection ofsetup.cfghad to be renamed totest_buildasit is otherwise interpreted as an option passed to
setup.py test,which it is not, right now. It may be advantageous to make
"work", but this would require more refactoring as
setupextiscurrently imported, and thus the choice of whether to use a local
freetype done, at the top of
setup.py, before we know whether we aregoing to run the test suite. This needs to be
documented.
Arguments to
pytestare passed as(as
setup.pywill swallow unspecified arguments itself).The remaining setups in
tests.pyare setting the recursion limit andturning on some deprecation warnings. I think the former can be
implemented as a local pytest plugin, and the latter as a session-scoped
fixture.
If we switch to this method, the CI scripts would need to be adjusted as
well.
The implementation is essentially copy-pasted from
http://doc.pytest.org/en/latest/goodpractices.html#manual-integration.
attn @tacaswell @phobson @QuLogic @Kojoley