webbpsf
webbpsf copied to clipboard
build(deps): bump matplotlib from 3.5.2 to 3.5.3
Bumps matplotlib from 3.5.2 to 3.5.3.
Release notes
Sourced from matplotlib's releases.
REL: v3.5.3
This is the third bugfix release of the 3.5.x series.
This release contains several bug-fixes and adjustments:
- Fix alignment of over/under symbols
- Fix bugs in colorbars:
- alpha of extensions
drawedges=True
with extensions- handling of
panchor=False
- Fix builds on Cygwin and IBM i
- Fix contour labels in
SubFigure
s- Fix cursor output:
- for
imshow
with all negative values- when using
BoundaryNorm
- Fix interactivity in IPython/Jupyter
- Fix NaN handling in
errorbar
- Fix NumPy conversion from AstroPy unit arrays
- Fix positional markerfmt passed to
stem
- Fix unpickling:
- crash loading in a separate process
- incorrect DPI when HiDPI screens
Commits
d04c8de
REL: v3.5.3318cacc
DOC: Update release notes for 3.5.3f4d4b47
Merge branch 'v3.5.2-doc' into v3.5.x071413e
DOC: Update GitHub stats for 3.5.30428306
Merge pull request #23591 from meeseeksmachine/auto-backport-of-pr-23549-on-v...2f3abfb
Merge pull request #23593 from QuLogic/fix-flake8530457e
STY: Fix whitespace error from new flake8ab78318
Backport PR #23549: Don't clip colorbar dividers952227e
Merge pull request #23528 from meeseeksmachine/auto-backport-of-pr-23523-on-v...632e4d7
Backport PR #23523: TST: Update Quantity test class- Additional commits viewable in compare view
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase
.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
-
@dependabot rebase
will rebase this PR -
@dependabot recreate
will recreate this PR, overwriting any edits that have been made to it -
@dependabot merge
will merge this PR after your CI passes on it -
@dependabot squash and merge
will squash and merge this PR after your CI passes on it -
@dependabot cancel merge
will cancel a previously requested merge and block automerging -
@dependabot reopen
will reopen this PR if it is closed -
@dependabot close
will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -
@dependabot ignore this major version
will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this minor version
will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this dependency
will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Codecov Report
Base: 62.04% // Head: 62.04% // No change to project coverage :thumbsup:
Coverage data is based on head (
b15adef
) compared to base (6d83a9d
). Patch has no changes to coverable lines.
Additional details and impacted files
@@ Coverage Diff @@
## develop #576 +/- ##
========================================
Coverage 62.04% 62.04%
========================================
Files 13 13
Lines 5304 5304
========================================
Hits 3291 3291
Misses 2013 2013
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.
@mfixstsci @BradleySappington and @ojustino I'd like to get your thoughts on this, please:
FYI, for WebbPSF, Shannon set up "dependabot" some time ago (long before she departed), which every month auto-generates many small trivial PRs which update the "requirements.txt" file to track the latest versions of various dependencies. She used to deal with all of them, merging them in sequence. I don't think these require much effort - not beyond "click approve", "click merge", etc. It's somewhat tedious though.
First question is, what do you think is current best practices for this sort of maintenance? What's done on other INS-maintained packages or other efforts led from MESA? I'm all for doing this in a consistent way.
Second question is, this approach makes the requirements.txt
file not really the "requirements", in the sense of "minimum version of all dependencies needed to install or run". Instead it becomes "this is the latest version of all dependencies, which gets used by the CI system to set up the environment for most test cases". The semantics are not the same. I don't have a strong opinion whether this is good or not. Again, it seems this should be done in a consistent way, or at least as consistent as possible, with other INS-maintained packages. It shouldn't be something we have to think about in a different or unique way for WebbPSF, ideally.
Hey Marshall,
These are great questions.
I’ll defer to @Mees @.***> for his expertise on how the rest of MESA handles this.
Maintaining dependabot PR’s is best practice in my opinion. There are always dependencies that are getting updated, and many times these updates happen for security purposes. It also helps devs find issues of obsolete calls that need to be updated. This will keep refactoring as inexpensive as possible as it should occur gradually. It may be easier to keep the versions older and keep the code as is, but that can will certainly bite us down the line (currently experiencing that with a project right now that’s 2 years without being touched).
WRT the name “requirements.txt”. In order for our code to run its best and be as secure as possible, it “requires” the most up to date and secure versions of the packages it uses…yes, I think that phrasing will let me sleep at night.
-Brad
From: Marshall Perrin @.> Reply-To: spacetelescope/webbpsf @.> Date: Wednesday, September 14, 2022 at 5:00 PM To: spacetelescope/webbpsf @.> Cc: Bradley Sappington @.>, Mention @.***> Subject: Re: [spacetelescope/webbpsf] build(deps): bump matplotlib from 3.5.2 to 3.5.3 (PR #576)
@mfixstscihttps://urldefense.com/v3/__https:/github.com/mfixstsci__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!wG7jdDeNLPdyYcO5b_VGnkS_hKkD8Yq5hildg9NQH1vz2Jr4U3EnzK3BZgjtaA3_KwOG6CkFT-S5x37Ee8SuVxg31iv_$ @BradleySappingtonhttps://urldefense.com/v3/__https:/github.com/BradleySappington__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!wG7jdDeNLPdyYcO5b_VGnkS_hKkD8Yq5hildg9NQH1vz2Jr4U3EnzK3BZgjtaA3_KwOG6CkFT-S5x37Ee8SuVz3-s4si$ and @ojustinohttps://urldefense.com/v3/__https:/github.com/ojustino__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!wG7jdDeNLPdyYcO5b_VGnkS_hKkD8Yq5hildg9NQH1vz2Jr4U3EnzK3BZgjtaA3_KwOG6CkFT-S5x37Ee8SuV_ANA8Rp$ I'd like to get your thoughts on this, please:
FYI, for WebbPSF, Shannon set up "dependabot" some time ago (long before she departed), which every month auto-generates many small trivial PRs which update the "requirements.txt" file to track the latest versions of various dependencies. She used to deal with all of them, merging them in sequence. I don't think these require much effort - not beyond "click approve", "click merge", etc. It's somewhat tedious though.
First question is, what do you think is current best practices for this sort of maintenance? What's done on other INS-maintained packages or other efforts led from MESA? I'm all for doing this in a consistent way.
Second question is, this approach makes the requirements.txt file not really the "requirements", in the sense of "minimum version of all dependencies needed to install or run". Instead it becomes "this is the latest version of all dependencies, which gets used by the CI system to set up the environment for most test cases". The semantics are not the same. I don't have a strong opinion whether this is good or not. Again, it seems this should be done in a consistent way, or at least as consistent as possible, with other INS-maintained packages. It shouldn't be something we have to think about in a different or unique way for WebbPSF, ideally.
— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/spacetelescope/webbpsf/pull/576*issuecomment-1247296611__;Iw!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!wG7jdDeNLPdyYcO5b_VGnkS_hKkD8Yq5hildg9NQH1vz2Jr4U3EnzK3BZgjtaA3_KwOG6CkFT-S5x37Ee8SuV6byxbQd$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AYEBMN2YOD3OFIMSQPWD2KTV6I4GVANCNFSM6AAAAAAQCGDAFM__;!!CrWY41Z8OgsX0i-WU-0LuAcUu2o!wG7jdDeNLPdyYcO5b_VGnkS_hKkD8Yq5hildg9NQH1vz2Jr4U3EnzK3BZgjtaA3_KwOG6CkFT-S5x37Ee8SuV2F0O3wl$. You are receiving this because you were mentioned.Message ID: @.***>
@mperrin --- @BradleySappington pretty much touched all of the points here. Although the version changes are incremental and sometimes seem unnecessary it will save us time in the long run. Using the automatic dependency updating bots are also a requirement for the INS community software tools.
Most of the time when updating these packages, we just merge them as they come in. The process for maintaining the dependencies can be different depending on what the package needs and supports. From what I see, therequirements.txt
file is updated and then a pull request is issued. This is the standard work flow when using these types of tools (in my experience).
From what I can see, the changes are installed and the used in the CI. I haven't spent much time looking into this, but when I looked at the details of the CI runs, I see that the most up-to-date version of matplotlib
is being installed.
Great sounds good. Thanks for confirming that all that Shannon set up is still the state-of-the-art & recommended best practice, and consistent with the other INS tools etc. That's what I had hoped you'd say :-)
Superseded by #586.