Support end date for basemap
wreckdump opened this issue · comments
First of all, thank you for maintaining this python module.
I was wondering when the maintenance would actually come to a full stop. I thought this module would be completely stop being maintained at 2020, but it seems that it is still actively being (or just stretching out) maintained by Víctor Molina García (thank you again!).
I mean, if it is possible I would like to somehow contribute in maintaining it so that anyone who would like to use this module could use it as long as they can.
I don't see any reason it can't be maintained as long as sufficient people like Victor and yourself keep maintaining it. That's the way open source software works. I'm also very grateful to @molinav for working with it.
@wreckdump My current work is mostly focused in the packaging part: providing precompiled wheels is the main step to make basemap easier to install for an end user. Although I am still testing before tagging a new basemap stable release (1.3.0), the precompiled wheels seem to be working for Windows and GNU/Linux (x64 and x86 bits) for Python 2.7 and 3.5-3.9, and we now have GitHub Actions generating these wheels. I think that once we have one first stable, distributable release in PyPI (1.3.0), I will move through the open issues in order to fix known bugs.
I do this mostly during my free time, so the progress depends a bit on my availability. Anyone is welcome to contribute in basemap; as @efiring said, this is how open source projects remain alive. There is always something to do or improve. For example, I have no idea about preparing wheels for MacOS, so I would appreciate a lot some help there. Also, the repackaging into three separate packages seem to break pip installations that point to the basemaprepository directly, since there is no setup.py file anymore at the project top-level, and for which I haven't still found a solution.
@wreckdump The stable release 1.3.0 is finally available in PyPI.
@molinav Thanks!
I personally am not using MacOS nor I own any machine.. So I don' think I could help with that. I could look into the issue of the setup.py.
Asked on X matplotlib for an update of the deprecation message on https://t.co/TyRaO5poOk
@ReimarBauer I think I removed the deprecation text some months ago in the docs, but when I ran Sphinx it failed because the docs are quite outdated and some things are not working anymore (e.g. plots based on netCDF4 files from a not-found url).
I would like to take a look to this in the following weeks if I manage to book some spare time, and include the docs build process into the GitHub workflow.
I had not known that the docs are in basemap. I try to make it runnable by sphinx again ;)
@ReimarBauer I have added one additional "docs" job in the basemap-for-manylinux workflow. With some minor changes in the conf.py file it is possible to run with a recent Sphinx version. There is a couple of issues due to old matplotlib syntax or a missing remote netCDF4 file, but the errors are ignored and the docs build continues until the end. The generated documentation can be seen in the browser, only with a couple of things missing due to the former errors.
My goal now would be to add one additional "pages" job that is triggered only for tags, and which receives the "docs" artifacts and uploads them to the appropriate place (GitHub Pages?).
I would like to close this issue once the documentation gets the deprecation noticed removed. However, as I already mentioned in #568, something is not configured properly for the GitHub Pages deployment workflow, because the workflow shows success but the basemap docs website never gets updated. I do not know if having a custom domain for the docs is playing a role.
I defined this long time ago for our project. I used for pages a different repository but I think that is not needed, branch name should be enough.
There I added to the repository for the github pages a pages configuration.
It was important that the branch name for the docs was named gh-pages as you do
see https://docs.github.com/en/pages/getting-started-with-github-pages/configuring-a-publishing-source-for-your-github-pages-site
our config:
The pages gets in our case updated once I merge something into the gh-pages branch. There is no need for a deployment script. Of course I like the idea :)
I missed to screenshot a line on top:
Your site is live at URL
Is there the correct url?
@molinav We used the docs folder for example, https://github.com/Open-MSS/Open-MSS.github.io/tree/gh-pages/docs
@ReimarBauer This is how it looks right now:
In this case, the default directory is the root, but this is on purpose, because the gh-pages branch only hosts the documentation directly from the top-level directory. Updating the gh-pages branch triggered a dynamic website docs deployment here:
https://github.com/matplotlib/basemap/actions/runs/7370618816
There everything appears as successful (funnily, I can even read that the docs were deployed 2 hours ago), but the docs remain outdated after it. The only difference that I can see is that the docs are not using the default GitHub link for pages, but rather the http://matplotlib.org/basemap link. If I try to go to the default https://matplotlib.github.io/basemap link, I am redirected to the other one.
I remember that I had also trouble but not exactly what it was. At the end I used the docs folder. May be this makes a difference. If not tried maybe last option?
My use of the root directory here comes from mimicking what the people at pyproj are also doing, see below (I even copied the symlinks for stable and the top-level index.html file):
https://github.com/pyproj4/pyproj/tree/gh-pages
whose last deployment is found here:
https://github.com/pyproj4/pyproj/actions/runs/6793359195/job/18468066062
The root directory has been the reference folder to create the tar archive for the pages as far as I can remember, I guess @WeatherGod made this successfully at some point in the past for v1.2.1. I think the problem might be coming most likely from the use of the custom http://matplotlib.org/basemap link, but I do not know exactly who could be of help here (@tacaswell or @efiring maybe?).
If I go to our last docs build job, the logs show that the tar archiving is doing what it should do (i.e. it is picking the new ./1.2.1 folder, the new index.html, and the new stable symlink), so the issue must come from the upload job afterwards:
https://github.com/matplotlib/basemap/actions/runs/7370618816/job/20057151741
For completeness, the docs publishing issue has been fixed.
The latest docs are live in https://matplotlib.org/basemap (stable points temporarily to latest, because indeed latest is more stable than 1.2.1; after release 1.4.0, stable will start pointing again to the last released tag).
The latest docs fix all the broken examples in the documentation. All the broken links are also replaced with the correct ones. The installation process has also been added, based on what we already had in the README but adding hints for conda-forge installations.
Similarly to what I mentioned in #568, I am very happy with the last two years of maintenance:
- Lots of bugs fixed, a lot of them by the users that found the problem through PR, so users are still willing to contribute.
- Regular releases to PyPI and to conda-forge, with precompiled wheels or conda packages, thus less people struggling with the build process (mostly because GEOS does not build successfully). And even if having to build from source, the steps are well described and with a
GeosLibraryhelper class that makes the build less painful.
The deprecation notice is gone from the docs, because I am not planning to step out in the short/mid future, so at the moment I would say there is no support end date for basemap. So with your permission I will be closing this issue, so that the focus is moved to the issues with bugs needing for help!