-
Notifications
You must be signed in to change notification settings - Fork 2
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
Unpinned dependencies #10
Comments
This is intentional!
For that reason, we want to limit the constraints we place on the dependencies of I am not familiar with Does that make sense? |
Aha, I see. Indeed, pinning dependencies could cause conflicts with other packages. On the other hand, it would make the splits reproducible, which may not be the case right now. Anyway, I respect that this decision was intentional and will close the issue. I just wanted to highlight it, because I often couldn't reproduce scientific repositories (models, not packages) due to this issue. |
I think the split should be reproducible, as long as we are careful about setting the random seed! It could be that dependencies are updated without respecting backwards compatibility, but with the mature nature of most packages we use I think this is unlikely. |
At the moment, neither the dependencies in
project.toml
nor the developer dependencies inenv.yaml
are pinned. This might create subtle discrepancies between developers and the pip package, leading to unreproducible bugs and software rot.Solution: Pin the dependencies. Install the environment, run
pip freeze
, and pin the installed versions in the.toml
and.yaml
files.I like pip-tools, but I haven't used it for
.toml
and conda environments.Alternatively, it could be postponed, e.g. until a stable release, but we need to be aware of these subtleties.
The text was updated successfully, but these errors were encountered: