Bumped CI dependencies #279
Conversation
Codecov Report
@@ Coverage Diff @@
## master #279 +/- ##
=======================================
Coverage 75.51% 75.51%
=======================================
Files 44 44
Lines 5129 5129
=======================================
Hits 3873 3873
Misses 1256 1256 Continue to review full report at Codecov.
|
|
This is in preparation for the 1.2 release that |
tox.ini
Outdated
| @@ -1,6 +1,6 @@ | |||
| [tox] | |||
| envlist = | |||
| py{37,38,39}-{latest,astropy40,astropy41} | |||
| py{37,38,39,310}-{latest,astropy42,astropy43,astropy50} | |||
There was a problem hiding this comment.
you need to define dependency rules for these new versions below.
Also, do you plan to drop astropy 4.0 support?
Either case, what I would suggest is to have one called oldestdeps or similar, that always have the same versions as you have in the package configs as minimum required dependencies to ensure the package is actually compatible with that version combination. And then also to have one job that runs with all on the latest-and-greatest. And whether you test with everything in between is less critical.
There was a problem hiding this comment.
It sounds reasonable.
It looks like 4.0 doesn't work with Python 3.10 so I had to drop it.
There's currently no minimal astropy version in setup.cfg but I will add it. I'm not sure how to centralize that oldestdeps/latestdeps info in one place. It is used in setup.cfg, tox.ini and GH Actions. Do you already have an example of how to achieve that?
There was a problem hiding this comment.
Oh, we never assume that all combo will work, e.g. 4.0 shall work with all the versions that were the recent ones when it was released. It's never an expectation that it works with the current latest and greatest. (E.g. oldest combo could be astropy 4.0 with numpy 1.16 etc, even though those are not 3.10 compatible. But then of course dropping them is reasonable, too. NEP-29 (https://numpy.org/neps/nep-0029-deprecation_policy.html) and SPEC-0 are good rule of thumb to follow, e.g. don't drop versions before those timelines, but it's fair game once something is as old as in those guidelines: https://scientific-python.org/specs/spec-0000/)
There was a problem hiding this comment.
There's currently no minimal astropy version in setup.cfg but I will add it. I'm not sure how to centralize that oldestdeps/latestdeps info in one place. It is used in setup.cfg, tox.ini and GH Actions. Do you already have an example of how to achieve that?
You can use e.g. astroquery as an example. setup.cfg sets the minimum supported. I like to set it even when it's not strictly necessary, but think about it as a guarantee that those versions would work. Then they need to be repeated in tox.ini to make sure they are indeed tested and work together.
The nice thing with tox is that then you don't need to repeat the versions anymore in GHA (or any other CI you may use), just use the name of the job, and update the versions for that job in tox whenever needed.
|
Hi, for the NAVO pyvo workshop at AAS 239 in Salt Lake City, we want to freeze the content and installation instructions on December 15th. That's one week away. What else is needed for this PR to complete? |
|
@bsipocz I think this makes it more clear - thanks for the suggestions. Next time we will re-work the workflow file to simplify it using |
| astropy | ||
| requests |
There was a problem hiding this comment.
These should be picked up from the setup file, don't need to list them out in tox (unless of course you want to set a version number for them), but you may need to add an [options] section, too (I'm not sure whether dependencies would be properly picked up from [metadata])
No description provided.