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
Triggered by #609, as well as by #584 and related issues, I think we need a mechanism to make the versions of our Python dependencies very specific every time we release a new distribution, for reproducibility reasons.
This could be included in a release pull request template here, and maybe there is some Action or similar mechanism to check the version restrictions in requirements.txt files.
However, if we do this by changing the actual files here, we would need to merge back-and-forth, which would be a bit ugly.
An alternative would be something like a Gemfile.lock approach, where we would specify a set of versions that are known to work in a separate file (for example requirements-reference.txt).
The text was updated successfully, but these errors were encountered:
We could also fix the direct dependencies in the requirements.txt.
Common packages like numpy and scipy would be good candidates.
preCICE should remain in compatibility mode though.
And we need to fix the solvers anyway.
Triggered by #609, as well as by #584 and related issues, I think we need a mechanism to make the versions of our Python dependencies very specific every time we release a new distribution, for reproducibility reasons.
This could be included in a release pull request template here, and maybe there is some Action or similar mechanism to check the version restrictions in
requirements.txt
files.However, if we do this by changing the actual files here, we would need to merge back-and-forth, which would be a bit ugly.
An alternative would be something like a
Gemfile.lock
approach, where we would specify a set of versions that are known to work in a separate file (for examplerequirements-reference.txt
).The text was updated successfully, but these errors were encountered: