Don't run CI on mdanalysis latest + latest python #93
Conversation
{{cookiecutter.repo_name}}/.github/workflows/{{cookiecutter._ci_name}}.yaml
Outdated
Show resolved
Hide resolved
| steps: | ||
| - uses: actions/setup-python@v4 | ||
| with: | ||
| python-version: "3.11" | ||
|
|
||
| - id: get-compatible-python | ||
| uses: MDAnalysis/mdanalysis-compatible-python@main | ||
| with: | ||
| release: "latest" |
There was a problem hiding this comment.
Right this is my short term fix - updated mdanalysis-compatible-python to have a latest option.
This means that this CI matrix has no way of checking for compatibility with the latest versions of Python...
There was a problem hiding this comment.
Thank you for looking into this and opening this @IAlibay -- for now, LGTM as an interim fix!
However I think I prefer your Option 2 that you outlined there, so that we can keep testing develop with the newest and greatest. Unless I'm missing something, I don't see many downsides aside from additional CI complexity (maybe a slightly larger matrix?) @orbeckst @ianmkenney @fiona-naughton do you have any opinions here?
Yeah this is going to be a hassle now and in the future -- when there's time I'd like to look into a bot or similar that can keep watch on changes to the cookiecutter and maybe open PRs with cherry-picked changes when we update cookie-related things. |
There was a problem hiding this comment.
I am ok with the band-aid.
(As @lilyminium said, option 2 is better mid-term.)
In all cases we're going to have to go to the MDAnalysis cookie-cutter using repos and fix this workflow, because right now all their CI is failing.
Yikes. Is there a way we can move "this" into an action that we can fix centrally? (Well, discussion for another issue.)
* Update deployment for OIDC (trusted publisher) * Exclude latest python from latest mda deploiyment (using hot-fix "latest", see MDAnalysis/cookiecutter-mdakit#93 for background)
A long term solution here is great, and I'm happy to have that discussion - indeed there is lots we can do. However, the intent of that comment was "who takes responsibility for dealing with this today". I don't want to spend time cycling on this too much, so I've already added the short term fix to PRs to transport-analysis, waterdynamics, pathsimsanalysis and mdaencore. @ianmkenney @orbeckst @fiona-naughton @lilyminium If there are any other MDAKits that you know need updating, please either chime in here with the list of mdakits or spread the fix around. |
This is to be discussed elsewhere, but the current Honestly my long term opinion here is that, if we want to build our user community, we should, like numpy and scipy, take on the responsibility of having a Python 3.12 release as soon as possible. However that's a core library time & efforts allocation issue. |
|
Sounds like a good insight, born from experience. Do we have a document with our maintenance aspirations? At least internally we should have an idea what our goals are. |
|
I don't think we've written down maintenance aspirations in that way before, although of course @IAlibay would know better here. There is a related maintenance SDG application but it focuses more on dev docs and CI/CD utilities. Not to cut the discussion short, but I might merge this PR given the approvals just we can get CI back for now! |
|
Thank you again @IAlibay for the fix! |
Fixes #92 (I think)
This might need some discussion.
Currently CI will run all the versions that the develop version of MDAnalysis will support.
This will cause failures when it attempts to run a brand new version of Python that the last release of MDA doesn't support (for example Python 3.12 + MDAnalysis 2.6.1).
There are two options I can see out of this:
In all cases we're going to have to go to the MDAnalysis cookie-cutter using repos and fix this workflow, because right now all their CI is failing.
PR Checklist