Skip to content
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

Add upper bounds to dep versions #557

Merged
merged 1 commit into from
Jun 5, 2022
Merged

Add upper bounds to dep versions #557

merged 1 commit into from
Jun 5, 2022

Conversation

adamjstewart
Copy link
Collaborator

Another attempt to make TorchGeo more stable. Assuming that our dependencies follow semver, this PR assures that each TorchGeo release will continue to build for the indefinite future.

For a concrete example of why this PR is necessary, our 0.2.1 release currently doesn't work with the latest version of torchmetrics since 0.9 introduced a backwards-incompatible change (fixed in #555). Our 0.2.0 and older releases also doesn't work with torchmetrics 0.8 due to another backwards-incompatible change (fixed in #361, #382). Since neither release specified an upper bound on the torchmetrics dependency, the simple pip install torchgeo no longer works, you have to manually specify a compatible version of torchmetrics too. In Spack and Conda, we can specify this restriction after the fact, but this isn't possible with pip without a new release.

Caveats:

  • This PR assumes our dependencies know about and care enough to follow semver properly. It remains to be seen how closely our dependencies follow semver. Luckily, none of our dependencies use non-semver versioning schemes like dates.
  • These upper bounds need to be updated any time a new major release (or minor release for 0.X versions) comes out. We'll see how this interacts with dependabot. For now, I'm following the GitHub release announcements for all of our dependencies, so that should be sufficient to catch these kinds of things.

Closes #544

@adamjstewart
Copy link
Collaborator Author

I don't think it's necessary to do this for our environment.yml file, but we should do it in our Spack and Conda recipes. Will update those during the next release.

@adamjstewart adamjstewart added this to the 0.2.2 milestone Jun 5, 2022
@calebrob6
Copy link
Member

Why not necessary in environment.yml?

@adamjstewart
Copy link
Collaborator Author

Because environment.yml isn't included in the sdist (*.tar.gz) or bdist (*.whl) in our PyPI releases. This change is really only required to make sure that pip install continues to work, it doesn't affect Conda or Spack in any way. Honestly, I kinda want to get rid of environment.yml. It's only needed because Conda doesn't support installing from main like pip and Spack do.

@adamjstewart adamjstewart merged commit 28aa174 into main Jun 5, 2022
@adamjstewart adamjstewart deleted the versions/upper branch June 5, 2022 22:37
@adamjstewart adamjstewart modified the milestones: 0.2.2, 0.3.0 Jul 2, 2022
@adamjstewart adamjstewart mentioned this pull request Jul 11, 2022
yichiac pushed a commit to yichiac/torchgeo that referenced this pull request Apr 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add upper bounds to all dependencies
2 participants