-
Notifications
You must be signed in to change notification settings - Fork 7
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
Can we use compatible release spec in environment.yml? #46
Comments
Thanks Matt for raising this issue! In general, I'm in agreement with you on having a loosely pinned conda On whether using To be fair, I'm not against using Edit: Sorry, I just realized you're part of the cryoclouduser team already! In that case, I should ask if you're keen to help review future issues/PRs related to dependency upgrades. |
https://prefix.dev/blog/the_python_packaging_debate ☝️ Excellent article! @betolink shared this with me earlier this week. I don't like calver, personally; there's no specification method (aside from e.g.
This is always the challenge with complex environments. Sometimes I'm away from a project from 3 years and cleaning up the mess at that point is always a nightmare.
I'm absolutely willing to help out with environment-related changes. I'm feeling fairly comfortable with the tools you're using for this repo after doing these two PRs today! |
Cool, we've decided to go ahead to relax the dependency pinnings, beginning with a few packages in #56. Currently the |
Hello all,
My usual practice with
environment.yml
is to use compatible release spec to make upgrades easier, and a lockfile for reproducibility. Since this repository has a lockfile, what do you think about modifying theenvironment.yml
to not pin dependencies as strictly? This article speaks to the different use cases of these two types of spec files: One focuses on specifying a human-curated environment optimized for upgradeability, while the other optimizes for reproducibility and is generated by machine from a real environment.Compatible release spec allows specifying an arbitrary number of version digits, e.g.
~=1
,~=1.2
, or~=1.2.3
. The last digit specified is allowed to "move", and others are not. If you specify~=1.2.3
, version1.2.4
would be allowed, but1.3
would not. This provides some advantage over greater/less-than spec because in my experience a spec like>=3.0,<4.0
can allow a4.0.0alpha1
package to be installed. Perhaps this issue has been long-since resolved, but it's the reason I stopped using that style.In PR #45 I used compatibility spec out of habit and then realized the inconsistency. Happy to change it or not (or, if desired, overhaul the entire
environment.yml
file to use compat spec) depending on discussion outcome :)Thanks all!
The text was updated successfully, but these errors were encountered: