Modernize CI build

[cvanelteren]

This was rather frustrating to figure but I have gotten it to build using CI and not touching the other part of the codebase. The major issue was that some of the docs on CIBUILD were confusing with paths changing without really good documentation on it. At least the CIBUILD is transferred now and we can move on to other things. There are some warnings that needs addressing in another PR.

[cvanelteren]

I need to add the pytest but otherwise it looks good

[molinav]

I added some comments to your changes. The only one that is important is the one regarding the missing auditwheel repair (targeting manylinux2014/manylinux_2_17), the rest is all minor.

[cvanelteren]

The wheels seems to be missing the data still:

Archive:  wheels-basemap-windows-latest.zip
  inflating: wheels/basemap-1.5.0.dev0-cp310-cp310-win_amd64.whl  
  inflating: wheels/basemap-1.5.0.dev0-cp311-cp311-win_amd64.whl  
  inflating: wheels/basemap-1.5.0.dev0-cp312-cp312-win_amd64.whl  
  inflating: wheels/basemap-1.5.0.dev0-cp39-cp39-win_amd64.whl  
 Archive:  wheels-basemap-ubuntu-latest.zip
  inflating: wheels/basemap-1.5.0.dev0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl  
  inflating: wheels/basemap-1.5.0.dev0-cp312-cp312-manylinux_2_17_x86_64.manylinux2014_x86_64.whl  
  inflating: wheels/basemap-1.5.0.dev0-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl  
  inflating: wheels/basemap-1.5.0.dev0-cp39-cp39-manylinux_2_17_x86_64.manylinux2014_x86_64.whl  

[molinav]

If you mean the additional data files (boundaries, rivers, etc.), they belong to basemap-data and basemap-data-hires, and these packages are generated (in sdist and wheel form) in two other artifacts by the workflow.

But now that you mentioned this, I realised that what we are missing is the sdist version of basemap itself. We only have precompiled wheels for basemap, but the source distribution also needs to be generated.

[cvanelteren]

The sdist is added. Should the data artifacts be merged or this done in the process?

[molinav]

I think it is fine for now to have separate artifacts, as long as the upload job picks all of them later.

[molinav]

I want to pick one wheel for Windows and one for GNU/Linux to see that they install and import properly on my machine, and then it is time to merge!

[molinav]

@cvanelteren I am merging your PR now. I want to play a bit more with a couple of things, but I can make it in a separate branch in my fork without delaying your PR more. In the future I would like to:

• Improve the setup of GEOS_DIR (it is working but not as I would be expecting).
• Make before_all platform-independent. For this, a Python script in .github/workflows can be added doing what the before_all snippets are doing right now.
• At some point, linting (at least flake8) and testing (with pytest) need to be added back to the workflow.

Thanks a lot for your effort!

[cvanelteren]

No worries @molinav. I can assist in this if you would like. To respond to your points

• I had some issues too with the build platforms having platform specific issues and or not working as expected. Hence the roundabout way of doing it. Moving it to a platform agnostic (read python centric) would benefit in future maintainability
• if the current implementation works, there is no need but I agree with the previous point I wrote here
• linting could be performed with a precommit to a a PR, pytest could be added to the current build work flow at the end stage. See our package for inspiration