check server stack version #79
Conversation
pyproject.toml
Outdated
| stac_spec_latest = [ | ||
| "pystac~=1.12.1" | ||
| ] | ||
| stac_spec_10 = [ | ||
| "pystac~=1.11.0" |
There was a problem hiding this comment.
I don't think this solves the issue.
It forces a lock in to older versions that might not receive appropriate bug fixes, whereas the STAC 1.0/1.1 are supposed to be backward-compatible.
The idea is to allow the creation of STAC 1.0 collections/items in case the remote server receiving them does not yet support 1.1, which could cause invalid parsing.
It seems the solution to invoke a pystac.set_stac_version with the desired version based on
stac-utils/pystac#1375 (comment)
And pystac>=1.12.1 would always be employed.
Ideally, the pystac.set_stac_version would be invoked with the applicable stac_version returned by the addressed catalog by URL, and the populator could optionally offer an override argument.
There was a problem hiding this comment.
Ok it sounds like you read this comment (#73 (comment)) after reviewing this here.
It forces a lock in to older versions that might not receive appropriate bug fixes, whereas the STAC 1.0/1.1 are supposed to be backward-compatible.
Yes, this is not ideal but we're limited by decisions made by the pystac developers.
The idea is to allow the creation of STAC 1.0 collections/items in case the remote server receiving them does not yet support 1.1, which could cause invalid parsing.
It would not be invalid. See stac-utils/pystac#1375 (comment)
Ideally, the pystac.set_stac_version would be invoked with the applicable stac_version returned by the addressed catalog by URL, and the populator could optionally offer an override argument.
If you believe that is sufficient then let's implement that
There was a problem hiding this comment.
Since it wouldn't be invalid to have the extra bands/eo:bands/raster:bands whether using 1.0 or 1.1, I think using pystac.set_stac_version would be the right approach.
If a server advertises that it supports only 1.0, it will simply ignore the extra 1.1 parameters, but won't start complaining that we sent it items marked as 1.1. That version would raise an error due to https://github.com/radiantearth/stac-spec/blob/ec002bb93dbfa47976822def8f11b2861775b662/catalog-spec/json-schema/catalog.json#L27-L31 if the server only handled 1.0.
By default, it seems reasonable to use 1.1.
The pystac.set_stac_version should be only an override in case of problem.
Either way, the latest pystac would be used.
fmigneault
added this to the 0.7.0 - Updates considering STAC 1.1 and new Extensions milestone
There was a problem hiding this comment.
Approving with temporary workaround to resolve STAC 1.1, conditionally to #79 post-check before bump release.
Adds checks to ensure that the version of the STAC spec that the server is running matches the one used by pystac before uploading any data.
Allows the user to specify the version used by the STAC catalog that is being uploaded to. Users can specify this either with a command line option or with an environment variable
PYSTAC_STAC_VERSION_OVERRIDESee initial discussion here: #73 (comment)