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

Github vs Pypi, xesmf vs pangeo-xesmf #27

Closed
zklaus opened this issue Jul 20, 2022 · 4 comments · Fixed by #30
Closed

Github vs Pypi, xesmf vs pangeo-xesmf #27

zklaus opened this issue Jul 20, 2022 · 4 comments · Fixed by #30
Labels
question Further information is requested

Comments

@zklaus
Copy link
Contributor

zklaus commented Jul 20, 2022

Comment:

We are having some trouble figuring out how best approach depending on xesmf.

Generally speaking, we declare all our dependencies in setup.py, but usually install everything from conda-forge. I consider this best practice because it leaves the user options on how to install dependencies, be that via their distributions package manager, from source, or whatever.

In the case of xesmf, this presents a conundrum because what will invariably be perceived as the official releases on Pypi use the name pangeo-xesmf, whereas in parallel releases on the github page and on conda-forge use the name xesmf. Note that this is not about the name of the conda-forge package, which is quite frequently different from the Pypi name, but about the dist-info inside of it.

How should this be addressed? Why are we using the Github releases instead of the Pypi ones and why are those built in different ways anyway?

@zklaus zklaus added the question Further information is requested label Jul 20, 2022
@valeriupredoi
Copy link

+1 from me too! I also noticed (but not relevant to the feedstock immediately) that the pangeo-xesmf perform CI build testing using an environment.yml containing purely conda-forge-located deps, whereas the actual package installs via a setup.py with deps grabbed from PyPi - might just be a dev CI and not production CI, but one can jump on a parallel train track very fast using such a CI. Anyhoo, back to main topic here 😁

@ocefpaf
Copy link
Member

ocefpaf commented Jul 21, 2022

It would be nice to raise those issues upstream in the pangeo-xesmf fork. The fork, and the PyPI rename, exists b/c the creator of the library went MIA and was the sole owner of the repo and PyPI namespace. So, to be able to continue with the project, the maintainers had to fork and rename it on PyPI. However, it is essentially the same software.

@zklaus
Copy link
Contributor Author

zklaus commented Jul 27, 2022

I opened pangeo-data/xESMF#183 to discuss this. Regardless, I think building from the PyPI release could be an option for conda-forge.

@zklaus
Copy link
Contributor Author

zklaus commented Apr 5, 2023

The upstream issue was resolved by recovering access to the PyPI project xesmf, see pangeo-data/xESMF#183 🎉. Starting with version 0.7.1 we can now build consistently from the PyPI releases again.

@zklaus zklaus mentioned this issue Apr 5, 2023
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants