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

Support policy for optional dependencies (contextily, geopandas, rioxarray, etc) #3456

Open
weiji14 opened this issue Sep 26, 2024 · 2 comments · May be fixed by #3616
Open

Support policy for optional dependencies (contextily, geopandas, rioxarray, etc) #3456

weiji14 opened this issue Sep 26, 2024 · 2 comments · May be fixed by #3616
Labels
maintenance Boring but important stuff for the core devs

Comments

@weiji14
Copy link
Member

weiji14 commented Sep 26, 2024

Opening a thread to discuss whether a formal policy should be put in place for testing optional dependencies listed under the pyproject.toml file at:

pygmt/pyproject.toml

Lines 41 to 48 in 9a12ae9

[project.optional-dependencies]
all = [
"contextily",
"geopandas",
"IPython", # 'ipython' is not the correct module name.
"pyarrow",
"rioxarray",
]

Originally posted by @weiji14 in #3420 (comment)

Thinking if we should generalize this to test minimum supported versions of all optional dependencies (contextily, geopandas, rioxarray, etc).

We should note that we currently don't set the minimum required versions for the optional dependencies.

Yeah, should we come up with a policy for this? E.g. extend SPEC 0 with a recommendation like:

  1. Support for optional package dependencies be dropped 1 year after their initial release.

For reference, xarray seems to use 12 months as the default for most dependencies - https://github.com/pydata/xarray/blob/v2024.09.0/ci/min_deps_check.py#L35. Downside with this is more maintenance effort, since we need to update the minimum pins for optional dependencies more often. We could also just state this policy, but not have an explicit pin?

@seisman suggested at #3420 (comment) the following:

I actually prefer to not set any minimum pins for optional dependencies and rely on the package manager like mamba/conda to install whatever versions that are compatible with the core dependencies.

So I guess we can do the following:

  1. Document the policy that optional dependencies are supported for 1 year only, i.e. users should use more up to date optional dependencies where possible.
  2. Do not set minimum pins on optional dependencies explicitly in pyproject.toml, but allow for breaking backwards compatibility (e.g. drop geopandas v0.x support) after 1 year.

Thoughts?

@seisman
Copy link
Member

seisman commented Nov 13, 2024

So I guess we can do the following:

  1. Document the policy that optional dependencies are supported for 1 year only, i.e. users should use more up to date optional dependencies where possible.
  2. Do not set minimum pins on optional dependencies explicitly in pyproject.toml, but allow for breaking backwards compatibility (e.g. drop geopandas v0.x support) after 1 year.

Thoughts?

Sounds good to me. For point 2, I think we still should set minimum pins if we know that old versions definitely won't work. For example, pin geopandas>=1.0 if we decide to drop geopandas v0.x.

@weiji14
Copy link
Member Author

weiji14 commented Nov 13, 2024

Sounds good to me. For point 2, I think we still should set minimum pins if we know that old versions definitely won't work. For example, pin geopandas>=1.0 if we decide to drop geopandas v0.x.

Ok, sounds good to me. For geopandas, the last non 1.x release is 0.14.4 (28 Apr 2024), so we could decide to pin to >=1.x on 28 Apr 2025. The other optional dependencies aren't too problematic yet I think, so we can just leave them unpinned until they cause issues.

@seisman seisman linked a pull request Nov 13, 2024 that will close this issue
@seisman seisman added maintenance Boring but important stuff for the core devs and removed question Further information is requested labels Nov 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance Boring but important stuff for the core devs
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants