Conversation
Codecov Report
@@ Coverage Diff @@
## master #8248 +/- ##
==========================================
+ Coverage 86.78% 88.36% +1.58%
==========================================
Files 387 367 -20
Lines 58110 54022 -4088
Branches 1060 316 -744
==========================================
- Hits 50428 47734 -2694
+ Misses 7067 6107 -960
+ Partials 615 181 -434
Continue to review full report at Codecov.
|
|
cc @drdavella |
astrofrog
left a comment
There was a problem hiding this comment.
This is great! Just a few small comments. It would indeed be nice to see this in use for AppVeyor too.
.travis.yml
Outdated
| TOXARGS='--remote-data=astropy' | ||
| # EVENT_TYPE='cron' | ||
| # CONDA_DEPENDENCIES="$CONDA_ALL_DEPENDENCIES clang" | ||
| # CCOMPILER=clang |
There was a problem hiding this comment.
For now, to keep this configuration equivalent, I think you could do:
EVENT_TYPE='cron'
CONDA_DEPENDENCIES=clang
CCOMPILER=clang
(I don't think this specific customization of the build belongs in tox.ini)
There was a problem hiding this comment.
I don't think it would work: I can pass CC to the tox env, but currently the CONDA_DEPENDENCIES are not installed in the tox-conda envs. There are still installed by ci-helpers in the root env though, which is useless. If we want to keep these customization of the test env by ci-helpers, we could split it in at least two functions: one to just install miniconda, and another that would be called in the tox env.
There was a problem hiding this comment.
Also why using conda's clang here ? osx is using clang by default isn't it ?
There was a problem hiding this comment.
Sorry I didn't reply to this sooner - I think the motivation for this might have been when we were considering adding some OpenMP functionality, but since we didn't do that in the end I think it's fine to drop this.
|
Tox seems to be interesting, but it would be good to clearly state what problem we are trying to solve with it, as it is another layer of indirection that may make the testing framework more, not less confusing (I'm certainly confused...). Also, definitely needs documentation! For instance, it has to be obvious what should go in Also, with this, the framework for astropy will diverge even more than is presently the case for the default setup for affiliated packages (which uses much more basic Ubuntu setups on travis - which I must admit I find easier to understand than what we do in astropy). It would be good if instead we could move to a model where astropy matches more closely what is done in the affiliated packages. Again good documentation will be key. |
|
Here's an unsolicited opinion: The other major motivation for Yet another motivation is that the use of TL;DR
|
| which python | ||
| pip freeze -l | ||
| pytest: pytest {posargs} | ||
| setup: python setup.py test {posargs} |
There was a problem hiding this comment.
I mention this in the comments, but I don't think that it makes sense to run setup.py test using tox. Basically this means that Astropy is creating yet another test environment within a tox environment, which, in my opinion, is exactly what we'd like to avoid. Maybe in the short term we want to maintain this as a sanity check, but our eventual goal should be to get rid of it.
There was a problem hiding this comment.
setup.py test is even actively discouraged in the docs: https://tox.readthedocs.io/en/latest/example/basic.html#integration-with-setup-py-test-command
This really should be simply pytest test {posargs}
tox.ini
Outdated
| -rpip-requirements-dev | ||
| commands = | ||
| pip install git+https://github.com/numpy/numpy.git#egg=numpy | ||
| pip install git+https://github.com/matplotlib/matplotlib.git#egg=matplotlib |
There was a problem hiding this comment.
Would it make more sense to move these to the deps section?
There was a problem hiding this comment.
This would conflict with pip-requirements-dev I think.
There was a problem hiding this comment.
Okay. I understand the reason for using a pip-requirements file but I wonder if you could have finer-grained control over dependencies by just including them specifically in the tox.ini file. Then you could prevent the conflict by using factors.
|
@drdavella - thanks for the explanation of the use! It would indeed seem good to reduce the extra code we now have to help us test things, etc., especially as so few of us understand how it works. In that respect, you made quite an improvement already by making it possible to run |
|
@mhvk - there were many discussions on this recently so I did not take the time to explain more, sorry. The goal is really to simplify things, so don't be afraid ;). |
|
@drdavella - about |
|
@saimn - OK, thanks. Please do link to those discussions at the top... |
|
@saimn yes that's reasonable, and I agree. We should just remember that the eventual goal should be to remove this duplication. Eventually I think it might be reasonable for |
| @@ -0,0 +1,68 @@ | |||
| [tox] | |||
| envlist = py{35,36,37}-{pytest,setup}{,-all},docs,dev,flake8 | |||
| skipsdist = True | |||
There was a problem hiding this comment.
Dosen't this mean that astropy dosen't get installed into an isolated environment by tox?
There was a problem hiding this comment.
This only means that no package should be built. That plays together with using usedevelop = True to test the project installed in develop mode (a.k.a. pip install --editable <project path>).
| setuptools >= 30.0.0 | ||
|
|
||
| [testenv] | ||
| usedevelop = True |
There was a problem hiding this comment.
Same comment as above about the skipsdist stuff?
|
Just to mention another benefit of tox: most of the configuration for CI then lives in a single file regardless of CI platform, which makes it much easier to switch between different CI services and also means that most users (once we do this in the package-template) will just need to worry about editing |
6d75e27 to
1be5d13
Compare
|
Latest news:
|
|
The pytest 3.7 builds are failing with doctestplus, is that a known issue ? cc @drdavella |
98ccd83 to
243bde2
Compare
|
I rebased and added the |
|
Tests are failing because of a Numpy multiarray failure on Windows, and pytest_plugins on Travis:
I hope that I did not introduce regression with the rebase.. |
|
Hi humans 👋 - this pull request hasn't had any new commits for approximately 5 months. I plan to close this in a month if the pull request doesn't have any new commits by then. In lieu of a stalled pull request, please consider closing this and open an issue instead if a reminder is needed to revisit in the future. Maintainers may also choose to add If this PR still needs to be reviewed, as an author, you can rebase it to reset the clock. If you believe I commented on this pull request incorrectly, please report this here. |
|
I'm going to close this pull request as per my previous message. If you think what is being added/fixed here is still important, please remember to open an issue to keep track of it. Thanks! If this is the first time I am commenting on this issue, or if you believe I closed this issue incorrectly, please report this here. |
|
Let's plan to re-open this once/if the APE on the future astropy-helpers is approved. |
This adds a tox config, with envs both for pytest and setup.py, and use it on Travis and CircleCI (docs).
If run in a python with conda and tox-conda, then a conda env is used.
So this still relies on ci-helpers to install miniconda, but then the other features like pinning versions are not used. Discussion needed here. We could imagine running a script inside the conda env to do what is done currently by ci-helpers, but I'm not sure about what exactly is needed here (it would probably be great to simplify this!).
TODO:
usedevelopis always used, I will come back to this later.See also: #8202