I don't have much expertise in this kind of thing (Windows or wheels) but I certainly think it could be nice!

No objection. I always feel a bit queasy about wheels for these packages that are backed by a whole stack (or web?) of binary dependencies. This is particularly true for these library style packages that must be used by some downstream program. Doesn't that lead to too much duplication and static linking?

But of course, if you think it's useful for someone and you are willing to support it, go ahead.

Doesn't that lead to too much duplication and static linking?

Yes but that is the definition of wheels :-/

But of course, if you think it's useful for someone and you are willing to support it, go ahead.

I won't use it but it is useful to folks that are lock in places that can only use pip. Sadly that's quite common.

gents @ocefpaf @zklaus call me Tail End Charlie, but it only now dawned to me that ESMPY is not on PyPI - is there any push to deploy it there after all? Am asking since I've just taken it out from our setup.py (soon to be pyrproject.toml), and frankly, am not too sure why I did that only now 😁

From the ESMF side, publishing ESMPy on PyPI has not been on our priority list but could potentially be if there was enough need from the community. What is your sense of the level of need, for yourself and others?

For some of my colleagues, ESMF not being on PyPI was one of the reasons for starting their own regridding package (xarray-regrid) instead of just using xESMF, so I would say there is demand.

Thanks for your comment, @bouweandela .

I can propose this to the ESMF team. I don't have experience providing packages on PyPI – especially those like ESMF/ESMPy that depend on a large compiled binary. Can anyone with experience with this give me a sense of how much effort it might take to set up and maintain a package like this for PyPI? e.g., would we likely be looking at more like a few days or a few weeks of effort?