try micromamba

[ocefpaf]

Debugging #1186

[ocefpaf]

@hmaarrfk I believe the changes in conda-forge/zlib-feedstock#62 broke the Windows CIs here. Using the previous version or build number before that PR works. As the author of that PR do you mind taking a look here and help us figure this out?

@jswhit this PR adds a workaround for the zlib issue but we should unpin it when the problem is fixed upstream. I'll leave to you if we should merge this or not. There are other changes that are worth keeping regardless of decision on the zlib pin.

[ocefpaf]

I believe the failure there is a network issue and should pass with restart.

[hmaarrfk]

conda-forge/libnetcdf-feedstock#146

[hmaarrfk]

is the issue that libnetcdf fails, or that this build here fails?

[ocefpaf]

is the issue that libnetcdf fails, or that this build here fails?

The build here fails. The debug info is in #1186 (comment)

[jswhit]

thanks for fixing this so quickly @ocefpaf !

[hmaarrfk]

do you have a build that just add zlib instead of pinning it?

[hmaarrfk]

feel free to squash.

[ocefpaf]

feel free to squash.

I'll leave that to @jswhit, not sure what he prefers. Thanks @hmaarrfk for the quick debug!

[jswhit]

If the fix upstream will happen soon, I'd prefer to wait for that. I'll leave this open in the meantime. Which changes in this PR do we need even after the upstream fix?

[ocefpaf]

If the fix upstream will happen soon, I'd prefer to wait for that. I'll leave this open in the meantime. Which changes in this PR do we need even after the upstream fix?

Sorry. I should've said before. @hmaarrfk figured out the real issue and it is that we were depending on an indirect pull of libzlib. B/c netcdf4-python depends on zlib directly we have to make it an explicit dependency, no need for workarounds with previous versions.

This should be good to go as-is.

[hmaarrfk]

To be clear, the "fix" upstream is the same as the fix here. Add zlib as a conda package at build time.
conda-forge/netcdf4-feedstock#138