feat(ext): Solar System extension "ssys"

[s-boomi]

Related Issue(s):

• (None)

Description:

• Added SolSysExtension in the extensions, the Solar System specification extension. See (https://github.com/stac-extensions/ssys).
• Added local_time, targets and target_class to SolSysExtension
• Added support for ssys v1.1.1. See (https://github.com/stac-extensions/ssys/releases/tag/v1.1.1).
• Added extension support for STAC Items, Collections, Summaries and Catalogs

PR Checklist:

• Pre-commit hooks pass (run pre-commit run --all-files)
• Tests pass (run pytest)
• Documentation has been updated to reflect changes, if applicable
• This PR maintains or improves overall codebase code coverage
• This PR's title is formatted per conventional commits

[gadomski]

@s-boomi honest question, to create this PR did you prompt a code-generating system with something like "Take https://github.com/stac-extensions/ssys/ and make a pystac extension for it?"

This isn't meant as a negative thing, this is just trying to understand the creation process. If it's this simple to create a PySTAC extension like this, I'm not sure it's worth merging it with main ... we could just give people prompts to make their own extension as-needed, or host a LLM-generated one somewhere else outside of the PySTAC codebase?

[s-boomi]

@s-boomi honest question, to create this PR did you prompt a code-generating system with something like "Take https://github.com/stac-extensions/ssys/ and make a pystac extension for it?"

This isn't meant as a negative thing, this is just trying to understand the creation process. If it's this simple to create a PySTAC extension like this, I'm not sure it's worth merging it with main ... we could just give people prompts to make their own extension as-needed, or host a LLM-generated one somewhere else outside of the PySTAC codebase?

I simply followed other examples already present in the extension folder. Besides, I already had a custom ssys extension beforehand for my other project. From then, aside from a couple of tests, it was mostly copying and replacing. The only instances I made use of LLMs in that case is to sniff potential checks, but for the most part, it was copypasting from other extensions.

I figured out adding the ssys extension to the main package was beneficiary for people working in planetary sciences like me. In my honest opinion, I think extensions should be placed in another repository altogether, much like pydantic_settings was for pydantic, and be curated by the community, following a set of specific guidelines.

[gadomski]

Cool, thanks for the explanation, I appreciate it. We see a lot of incoming code (in this repository and in others) that has been mostly/completely generated, and those tend to be harder to review b/c they have subtle errors and problems. Your context on your PR helps me "tune" my review, so thanks! 🙇🏼

In my honest opinion, I think extensions should be placed in another repository altogether, much like pydantic_settings was for pydantic, and be curated by the community, following a set of specific guidelines.

We're starting to move this direction, as of #1650. We had a similar problem in https://github.com/stac-utils/stactools/ and ended up settling on a whole new Github organization, https://github.com/stactools-packages/, to house the dataset-specifc repositories. I don't think we'll go that direction for pystac extensions; for now, separate-packages-but-same-repo seems like a decent compromise.