re-render feedstock, bump build number

[gboeing]

Checklist

• Used a fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[gboeing]

same error as was happening in conda-forge/geopandas-feedstock#49

[ocefpaf]

This one should pass as soon as we merge conda-forge/geopandas-feedstock#49

[gboeing]

Looks like same error is still happening?

[ocefpaf]

Looks like same error is still happening?

The new geopandas is not up yet. I'll restart the CI here when it is available in the channel. (The new Anaconda.org, that uses cloudflare, has a delay to get the packages available. You can check with conda search geopandas | grep 0.4.1.)

[ocefpaf]

OK. Now we are pulling geopandas 0.4.1-py_0 and the problem persists :-(

Investigating...

[ocefpaf]

I can confirm that, even with conda-forge/geopandas-feedstock#49, the problem remains. When doing:

conda create --name TEST python=3.7 geopandas

We still get libgdal 2.3.3 from defaults 😒

I'm going to try to "force" strict channel here just as an experiment. Hold on...

[ocefpaf]

While this is passing one will only be able to install osmnx when using the strict channel option.

We are between a rock and a hard place here and the GIS stack is pretty much broken without the strict channel option.

PS: a re-rendering will remove that change. I'll discuss with the @conda-forge/core to make that default in conda-smithy but maybe @msarahan will beat us by making it default in conda 4.7 😉

[gboeing]

While this is passing one will only be able to install osmnx when using the strict channel option.

Quick question about strict channel priority. If I run:

conda create -n TEST -c conda-forge --strict-channel-priority geopandas

with conda 4.6.7 on windows 10, I get:

Collecting package metadata: done
Solving environment: failed

UnsatisfiableError: The following specifications were found to be in conflict:
  - geopandas
Use "conda search <package> --info" to see the dependencies for each package.

I tested a few other packages, and the same thing happens if I replace geopandas with statsmodels, cartopy, or seaborn. Other packages however do solve successfully (bokeh or pillow, for example). Are these UnsatisfiableErrors expected? If so, how do I install these packages on windows with strict channel priority?

[ocefpaf]

I tested a few other packages, and the same thing happens if I replace geopandas with statsmodels, cartopy, or seaborn. Other packages however do solve successfully (bokeh or pillow, for example). Are these UnsatisfiableErrors expected? If so, how do I install these packages on windows with strict channel priority?

What platform is that? Windows or macOS? I can only test on Linux and all the packages you mentioned worked for me. I do know that on Windows we cannot use strict b/c conda-forge lacks a package for scipy. Not sure about macOS.

[gboeing]

conda 4.6.7 on Windows 10

[gboeing]

So if the GIS stack is broken without the strict option, and if strict doesn't work on Windows, how do we install on Windows at this point?

[ocefpaf]

So if the GIS stack is broken without the strict option, and if strict doesn't work on Windows, how do we install on Windows at this point?

Windows is a corner case where conda-forge relies a lot on defaults and therefore the exception to the strict channel. We should make that more explicit in the docs. macOS and Linux should prefer strict and Windows, until we package scipy, should not.

[gboeing]

Got it. Thanks @ocefpaf

[CJ-Wright]

@ocefpaf shouldn't strict have noticed that we don't have a windows scipy and properly pulled deps from defaults?

[ocefpaf]

@ocefpaf shouldn't strict have noticed that we don't have a windows scipy and properly pulled deps from defaults?

In theory yes. I test that and it did not work. Probably more unsatisfied deps and/or a bug in strict.

[ocefpaf]

Got it. Thanks @ocefpaf

I'm sorry that the state of things are half-broken/half-quasi-working but we are working on using the strict channel across conda-forge, see conda-forge/conda-forge-ci-setup-feedstock#50, and hopefully fix the SciPy dependency on Windows.

[gboeing]

Thanks! In the meantime, I'll tell linux/mac folks to use strict, and windows folks to not.

[ocefpaf]

Thanks! In the meantime, I'll tell linux/mac folks to use strict, and windows folks to not.

Thanks!

[gboeing]

uh-oh, this failed upon merge: https://circleci.com/gh/conda-forge/osmnx-feedstock/92

[gboeing]

I don't think I have permissions to re-start the CI workflow.

[ocefpaf]

I don't think I have permissions to re-start the CI workflow.

Just did it, but you should have as a maintainer :-/