Upgrade ckanext-spatial in the catalog-app
Description
In the catalog-app we are using a fork of the official ckanext-spatial extension (on the datagov branch).
As a part of a plan to upgrade CKAN extensions in use, and in order to improve the way that we manage forks we need to upgrade this extension.
Acceptance Criteria
- [ ] When there's a new release upstream, we can get onto it in under an hour
- [ ] When there's a new release upstream, we see a notification in a Slack channel
- [ ] If the upstream maintainers don't already use versioning, there's an issue in their tracker requesting they do.
- [x] If the upstream maintainers don't already have tests, there's an issue in their tracker requesting they add them.
- [x] We have tests for this extension running in CI. Done in upstream
Tasks
- [ ] Create a test environment with the catalog-app
- [ ] Upstream CI fails on CKAN <2.8. Fix it for the version we need.
- [x] Upstream do not use tags for versions, do not have a change log file and version is 0.2 since 9 years ago. Ask upstream for improve versioning: Done
- [ ] Test this extension
- [ ] Test geodatagov in catalog-app with spatial using upstream
- [ ] Measure the effort to move the catalog-app to this official spatial version.
Analysis & notes
The official repo has tests and CI. It is a very active, well documented and widely used version in the CKAN community.
Our fork is Ahead in 167 commits and Behind 120 commits. This potential PR show us the changes between our datagov branch and master at upstream
In a first analysis, we can see that in the GSA version we have a plugin cswserver/CatalogueServiceWeb with tests. This plugin was removed from upstream.
It's a good idea to define an environment with the catalog-app and just change spatial ext to the official version and run tests for this ext and GeoDataGov extensions.
Recommendation
We recommend moving to upstream version
I know for the CSW feature, there are discussions about pushing that necessity onto the geoplatform group, as that is a specific geospatial feature and not a core part of data.gov. It may still be necessary long term, but it is an ongoing discussion.
This is done in catalog-next and probably should be closed
We are still on a fork, and still need to merge upstream and/or move work to a different extension in order to remove this fork.