-
Notifications
You must be signed in to change notification settings - Fork 16
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
Test latest dependencies #344
Conversation
Codecov ReportAll modified lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #344 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 34 34
Lines 2868 2868
=========================================
Hits 2868 2868
☔ View full report in Codecov by Sentry. |
First pass done. Will the test become required if this PR was merged? Is there a way to avoid that? |
This can be configured in the GitHub settings. |
Once #339 is done I'll update this accordingly @williamjameshandley your gymnastics with version numbers in #335 has confused me even more how the test requirements work... |
just spotted a mistake in the README which imo fits in with the theme of this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is an issue with this idea, which is that if the next minor pandas/matplotlib releases and doesn't cause any problems, there's nothing to notify us that we should increment the anesthetic requirements
How about we add a test that runs after the latest dependencies test and checks whether the latest pandas and matplotlib minor versions are greater than our listed dependency?
As mentioned in #343, let's add another job that checks whether our matplotlib and pandas version requirements are up to date.
Problem is this doesn't tell us where the problem is |
Yeah, a check with pytest would probably be more helpful for reviewing, i.e. install with latest versions and then use pytest to make a version check against the versions listet in the dependencies. |
It would have to be separate from the rest of the tests, as this is not required to pass |
I'm quite a bit happier with this version. Currently includes an explicit list of |
Now automated to include all basic dependencies. Does come at the expense of bin/latest_dependencies.py involving a little more gymnastics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, just a question inline whether we could avoid the uploading to codecov, if not, then I'm happy with this.
.github/workflows/CI.yaml
Outdated
- name: Upload coverage to Codecov | ||
uses: codecov/codecov-action@v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need to upload to codecov for this job? If we don't then I'd prefer to leave this out. Faster and easier to review.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I should have flagged this earlier as I wasn't sure myself. @williamjameshandley what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the github settings will also need adjusting to control which tests are required to pass in order for a PR to be merged. I don't think I have access to these settings, @lukashergt can you check them? Maybe these tests will need to be put in a different file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are only branch protection rules for the master branch, so until this PR gets merged there is nothing to be done. Once this is merged we can individually remove jobs from the master branch protection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are all the jobs under CI separate or one in the settings?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Separate. Each job can be added/removed individually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgim then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgim
???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"let's get it merged", which I think is what @williamjameshandley thought I meant by "lgtm" (looks good to me, which I learned from pandas)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yeah, we had this before... I don't retain this stuff...^^
Fyi python 3.12 released a couple of days ago, and the tests are all passing fine (no new warnings anyway!). There's also a new m1 mac github runner we might want to run tests on https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/ Edit: this seems to be larger runners needing a bit more horsepower. I'm not sure what architecture the macos-latest runners are |
.github/workflows/CI.yaml
Outdated
- name: Upload coverage to Codecov | ||
uses: codecov/codecov-action@v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we remove the codecov upload for minimum-dependencies
, too? Not really what this job is about either, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree, since it is necessary that anesthetic works with the lowest versions we allow, and a PR should not be merged unless this is true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But codecov has nothing to do with whether anesthetic works or not, that is what pytest is for. Codecov should definitely be in the pip and conda jobs (or at least in one of them), but the coverage does not really depend on versions (unless we specifically add version related conditional statements to the code, which we don't). Besides, the minimum-dependencies
job does not even include extra dependencies, so it doesn't do a full code coverage anyhow...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the minimum-dependencies
code coverage were to fail, while the pip job code coverage passes, then we wouldn't even know about it, because as long as the pip jobs cover every line at least once, codecov will mark 100% coverage. But I don't even think it is possible for code coverage to be different for the pip jobs and the minimum job...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the tests are now different for matplotlib≥3.8, and at one point in beta some of the anesthetic plotting code was different for pandas 1 vs 2. cov would tell us when these lines are no longer needed right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll try it, but I think there will be missing coverage without minimum-dependencies
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the tests are now different for matplotlib≥3.8,
Code in tests/
doesn't matter for code coverage, only code in anesthetic/
matters.
and at one point in beta some of the anesthetic plotting code was different for pandas 1 vs 2. cov would tell us when these lines are no longer needed right?
In a situation like that we would indeed need the code coverage in minimum-dependencies
for as long as we wanted to be backwards compatible. However, we already have pandas>=2.0.0, so this shouldn't be an issue, here.
In fact, I think this might be an argument in favour of not having code coverage in minimum-dependencies
, to flag up once parts of code are no longer needed for newer versions. Currently we wouldn't know if parts of code were no longer needed by newer versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and at one point in beta some of the anesthetic plotting code was different for pandas 1 vs 2. cov would tell us when these lines are no longer needed right?
In a situation like that we would indeed need the code coverage in
minimum-dependencies
for as long as we wanted to be backwards compatible. However, we already have pandas>=2.0.0, so this shouldn't be an issue, here.In fact, I think this might be an argument in favour of not having code coverage in
minimum-dependencies
, to flag up once parts of code are no longer needed for newer versions. Currently we wouldn't know if parts of code were no longer needed by newer versions.
I guess it depends how cut-throat we want to be with older packages. I suppose the pandas2 difference was because pandas2 hadn't actually released yet, and once it did, we dropped support for pandas1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the tests are now different for matplotlib≥3.8,
Code in
tests/
doesn't matter for code coverage, only code inanesthetic/
matters.
Ah - I'd thought pytest --cov anesthetic tests
meant that coverage was looking at anesthetic AND tests, but tests is just to tell pytest where the tests are. I don't think I specified this in the new pytest calls
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that there might be a point where we'll want to re-introduce this for backwards compatibility, but I'd rather be aware when that happens.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a bunch @AdamOrmondroyd! Feel free to squash and merge.
@lukashergt done, please can you check that the PR settings are adjusted accordingly? |
New CI jobs are still not part of branch protection, so PRs won't require these. I guess new jobs need to be added manually to the branch protection rules. |
Cool, thanks for checking |
Thanks for taking charge of this, this makes anesthetic a lot friendlier to users other than ourselves. |
Description
Add upper limits to
pandas
andmatplotlib
versions, and add an additional test which uses the most recent releases.Also increase the README python version to 3.8+
Fixes #343
Checklist:
flake8 anesthetic tests
)pydocstyle --convention=numpy anesthetic
)python -m pytest
)