Emily Soth emlys

Fixing a botched python package release

Here's how I fixed the pygeoprocessing 2.3.3 release (with much help from James):

the problem

I uploaded an invalid sdist tarball to the 2.3.3 release on GitHub and PyPI.

the solution

I created a post release with the right sdist file. I repeated the entire release process with the version number 2.3.3.post0: updating HISTORY.rst, PRing that into main, pushing the new tag, waiting for artifacts to build, and uploading them to Github and PyPI.

I then yanked the 2.3.3 release on PyPI. This seems to be the best practice when a release is broken: PEP 592

about feature IDs

I couldn't find a complete specification for FIDs, but GDAL's vector data model docs say,

The feature id (FID) of a feature is intended to be a unique identifier for the feature within the layer it is a member of. Freestanding features, or features not yet written to a layer may have a null (OGRNullFID) feature id. The feature ids are modeled in OGR as a 64-bit integer; however, this is not sufficiently expressive to model the natural feature ids in some formats. For instance, the GML feature id is a string.

This suggests that all features read from a layer will have a defined FID, and all features will have an FID that is either defined or null. (Though it's not clear that that is guaranteed).

Format drivers may/may not enforce more properties of the FID. For instance, shapefile FIDs start at 0 while geopackage FIDs start at 1. Every time a shapefile changes, the FIDs are [re-ordered sequentially starting fro

initial setup

sudo apt-get install git
git clone https://github.com/ckan/ckan.git
cd ckan/
git checkout tags/ckan-2.9.5
cp contrib/docker/.env.template contrib/docker/.env
cd contrib/docker

# docker-compose up -d --build

	import os
	from osgeo import gdal, ogr, osr

	# Goal: Convert a CSV of point coordinates to a geopackage

	# Create a test CSV
	with open('test.csv', 'w') as csv:
	csv.write('latitude,longitude\n')
	csv.write('61,-150')