Skip to content

rebuild to get geos 3.10 into the package list #95

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

Merged
merged 6 commits into from
May 13, 2022

Conversation

ReimarBauer
Copy link
Contributor

Checklist

  • Used a personal 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.

@ReimarBauer ReimarBauer requested a review from molinav as a code owner May 13, 2022 07:23
@conda-forge-linter
Copy link

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.

@ReimarBauer
Copy link
Contributor Author

ReimarBauer commented May 13, 2022

seems not be possible for me to get the requirements for python_abi in py37 added
conda-forge/python_abi-feedstock#15

That is the reason for removing py37

@molinav
Copy link
Member

molinav commented May 13, 2022

I was a bit surprised to see that the recipe is already depending on GEOS >= 3.9, when it is known to cause bugs in basemap (see matplotlib/basemap#522). The recipe will have the same issues with GEOS 3.10 until the problem is solved on the basemap side, so accepting GEOS 3.10 is not a regression actually.

@molinav molinav merged commit b7d8314 into conda-forge:main May 13, 2022
@ReimarBauer
Copy link
Contributor Author

Thx for noting this geos problem. We had before a different problem for fixating it <3.9
I try if I can help with basemap 1.3.3

@molinav
Copy link
Member

molinav commented May 14, 2022

@ReimarBauer That would be of great help, since I am not a real expert on conda-forge packaging. This feedstock stays for the moment in basemap 1.2.x because for 1.3.x I made some significant changes in the basemap packaging which require an update in the conda-forge recipe (see #87).

To make the distribution of PyPI packages easier, I split basemap into basemap, basemap-data and basemap-data-hires, because this allows me to generate light wheels with the code for every Python version (basemap) and two universal data wheels for all Python versions (mandatory basemap-data and optional basemap-data-hires). I took this idea from the conda-forge package, whose recipe was splitting basemap into basemap and basemap-data-hires. The packages basemap-data-hires for PyPI and conda-forge are currently not identical (the PyPI package also contains the intermediate resolution data files).

The goal would be to have this new three-package structure also in conda-forge. For this, the conda-forge recipe needs to be updated, so that basemap-data-hires-feedstock gets archived and basemap-feedstock takes care creating these three new conda-forge packages. The Anaconda contributors have already migrated their recipe, see AnacondaRecipes@d5d5c3c. They tried to merge it here but both feedstocks have diverged too much and the merge was not possible.

I guess the most important part is to mimic what the Anaconda contributors did in their recipe folder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants