You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Use 2.10.0 for MDAnalysis Compatibility Matrix in CI Pipeline #181
The CI pipeline is currently failing due to wheel incompatibilities, likely introduced by the upgrade to Python 3.14. Instead of hard-coding or pinning specific MDAnalysis versions, the compatibility matrix should be updated to use latest.
This ensures that CodeEntropy is always tested against the most up-to-date MDAnalysis releases, helping prevent version drift and reducing maintenance overhead.
By switching to latest, we can maintain alignment with current MDAnalysis support and improve long-term CI stability.
Update:
Intead of using latest use MDAnalysis 2.10.0 to avoid potential issues discussed below
There is always the case using latest tags that CI fails from one PR to another and it is then more difficult to isolate if the failure was a code change locally or remotely. You also open up the issue that MDA might move faster than other python deps on latest and then you have dependency resolution issues down the line.
You should consider also the approach to use renovate to increment deps in pyproject.toml via PR this way you then don't merge failing version combos.
There is always the case using latest tags that CI fails from one PR to another and it is then more difficult to isolate if the failure was a code change locally or remotely. You also open up the issue that MDA might move faster than other python deps on latest and then you have dependency resolution issues down the line.
You should consider also the approach to use renovate to increment deps in pyproject.toml via PR this way you then don't merge failing version combos.
That's very true, what I can do instead of setting to latest then is to pin it to the most up to date version and then set up renovate to take care of updating the dependencies down the line then we would reduce the chance of failing combinations, I think this might be the best way to handle all of this, what's your thoughts?
Yeah I think it is worth exploring having monitoring of dep updates guarded via PR. I think you can get renovate to maintain version ranges as well, though I have not done this myself yet.
changed the title [-]Use `latest` for MDAnalysis Compatibility Matrix in CI Pipeline[/-][+]Use `2.10.0` for MDAnalysis Compatibility Matrix in CI Pipeline[/+]on Nov 17, 2025
Activity
jimboid commentedon Nov 17, 2025
There is always the case using latest tags that CI fails from one PR to another and it is then more difficult to isolate if the failure was a code change locally or remotely. You also open up the issue that MDA might move faster than other python deps on latest and then you have dependency resolution issues down the line.
You should consider also the approach to use renovate to increment deps in pyproject.toml via PR this way you then don't merge failing version combos.
harryswift01 commentedon Nov 17, 2025
That's very true, what I can do instead of setting to latest then is to pin it to the most up to date version and then set up renovate to take care of updating the dependencies down the line then we would reduce the chance of failing combinations, I think this might be the best way to handle all of this, what's your thoughts?
jimboid commentedon Nov 17, 2025
Yeah I think it is worth exploring having monitoring of dep updates guarded via PR. I think you can get renovate to maintain version ranges as well, though I have not done this myself yet.
[-]Use `latest` for MDAnalysis Compatibility Matrix in CI Pipeline[/-][+]Use `2.10.0` for MDAnalysis Compatibility Matrix in CI Pipeline[/+]