Pydantic 2 and STAC API 1.0

[thomas-maschler]

• Bump Pydantic to version 2.4.1
• Implement PEP 621 and use pyproject.toml
• Implement STAC API Specs 1.0.0

This PR addresses #124 and picks up the work started in #126 which seems stale.
It is currently blocked by developmentseed/geojson-pydantic#147

[vincentsarago]

@thomas-maschler thanks a lot for this 🙏 , just a couple comments for now but that's a really good start.

[gadomski]

Thanks for the PR! I should have done this sooner, but I've been hoping to archive stac-pydantic, as I find that it solves most of the same problems as pystac without much additional benefit. I've created this RFC to (briefly) lay out that rationale and gather feedback. @thomas-maschler (and anyone else), can you comment on that RFC with the reasons for updating and maintaining stac-pydantic? Once we have a discussion there, we can either close this PR and archive this repo, or get this PR to merge and continue maintaining.

Sorry again about the bait-and-switch, and thanks in advance for your input.

[codecov-commenter]

Codecov Report

Attention: 10 lines in your changes are missing coverage. Please review.

Files	Coverage Δ
stac_pydantic/__init__.py	100.00% <100.00%> (ø)
stac_pydantic/api/__init__.py	100.00% <100.00%> (ø)
stac_pydantic/api/collection.py	100.00% <100.00%> (ø)
stac_pydantic/api/collections.py	100.00% <100.00%> (+9.09%)	⬆️
stac_pydantic/api/extensions/context.py	100.00% <100.00%> (ø)
stac_pydantic/api/extensions/fields.py	91.30% <100.00%> (ø)
stac_pydantic/api/extensions/sort.py	100.00% <100.00%> (ø)
stac_pydantic/api/item.py	100.00% <100.00%> (ø)
stac_pydantic/api/landing.py	100.00% <100.00%> (ø)
stac_pydantic/api/links.py	100.00% <100.00%> (ø)
... and 14 more

📢 Thoughts on this report? Let us know!.

[gadomski]

Thanks for the contribution! In general makes sense to me -- the API structures in particular do seem to make more sense as pydantic models. Couple of nits about the tests to change.

At a higher level, could you add a note to the README clarifying the relationship between this library and pystac? My main motivation behind radiantearth/stac-spec#1252 is to avoid confusion in the community (and, until this PR, drop an un-maintained repo), and even a fixed up stac-pydantic may confuse newcomers as to "which repo should I use"? A README explanation could help that.

[rbavery]

curious if thiswill be merged soon? I'd like to use it in conjunction with a module I'm writing that uses Pydantic v2 to model a STAC extension for machine learning models.

It seems like there are only two nits to fix, @gadomski @thomas-maschler is it ok if I address these by removing the commented tests and the leftover print? are there other blockers to merging after that?

[thomas-maschler]

@rbavery , that would be great. I had to change focus in the meantime and I didn't get a chance to work on this again. I am not sure if I am testing the right way and removing the test probably won't do any harm.

[gadomski]

Yeah, @rbavery if those nits get cleaned up we can merge, then we'll want a release I reckon. I'm still hoping for some sort of resolution in radiantearth/stac-spec#1252 but for now no reason not to use @thomas-maschler's work ❤️.

[thomas-maschler]

Ok, this wasn't big of an issue. There were still some STAC API specific features which were tested in the the wrong place.
@gadomski can you please glance over this again. If we were to release this, what version would this be 3.0? Should I bump the version number for __version__?

As for finding a resolution for radiantearth/stac-spec#1252 I suggest we create a separate PR and update the Readme, clarifying that the main purpose of this library is to provide reusable request/response models for tools such as fastapi. For more comprehensive schema validation and usage of extensions, pystac is the recommended tool.

I am not sure if there is consensus about the lifecycle of this library, but it would be worth mentioning, that this library will be archived eventually.

[gadomski]

If we were to release this, what version would this be 3.0? Should I bump the version number for version?

Probably yes, but I need to look over again to be sure. Don't bother bumping in this PR, we'll have a separate release PR.

I suggest we create a separate PR and update the Readme, clarifying that the main purpose of this library is to provide reusable request/response models for tools such as fastapi. For more comprehensive schema validation and usage of extensions, pystac is the recommended tool.

I like this a lot 👍🏼.

[gadomski]

I've created a release branch, which includes a README note about this repo's relationship to pystac: #129.