You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
0 commit comments