Add third-party section, multi-tenant catalogs extension to readme

[jonhealy1]

Related Issue(s):

• /catalogs #886
• Multi-tenant /Catalogs Extension #880

Description:

• add a third-party extension section to the top-level README
• add a related external project reference in the third-party extensions docs page
• adds documentation for the external stac-fastapi-catalogs-extension project

This can be viewed as an alternative pr to #880

PR Checklist:

• pre-commit hooks pass locally
• Tests pass (run make test)
• Documentation has been updated to reflect changes, if applicable, and docs build successfully (run make docs)
• Changes are added to the CHANGELOG.

[gadomski]

If we keep the stac-fastapi-catalogs-extension as its own repo (and don't integrate it in #880) are we creating any headaches for users/implementers? Or is the usage story pretty simple, and they just have to depend on both?

If it's not a huge headache, I'm inclined to go with this PR's approach by just point to stac-fastapi-catalogs-extension in the docs. My reasoning is that there doesn't feel like there's a strong consensus on the need and implementation expressed in #880 (not saying it's wrong or right, just that there's not a consensus).

[jonhealy1]

@gadomski One argument for hosting it externally too is that the extension is still in active development.

[gadomski]

@gadomski One argument for hosting it externally too is that the extension is still in active development.

Sounds good ... if you're in agreement, maybe we can close #880 and just have this one to review (it's light)?

I haven't looked into the CI failures deeply, but it looks like some sort issue w/ min-mypy version on new Python.

[jonhealy1]

@gadomski How should I move forward with this? Should I try to create a new pr from main? It seems weird this passes on main.

[gadomski]

How should I move forward with this? Should I try to create a new pr from main? It seems weird this passes on main.

I believe this is a "bitrot" situation, specifically because mypy released a new version yesterday: https://pypi.org/project/mypy/1.20.0/. A good way to fix would be:

git checkout fix-mypy
uv run pre-commit autoupdate  # to update our pre-commit config w/ the new mypy version
uv run --with mypy --with types-attrs mypy -p stac_fastapi

And then fix the typing errors.

The root cause appears to be these two lines:

stac-fastapi/.github/workflows/cicd.yaml

Lines 37 to 38 in 5a1e78f

	uv run pre-commit run --all-files
	uv run --with mypy --with types-attrs mypy -p stac_fastapi

Specifically, the second one doesn't pin the mypy version, so it drifted to the new version on this PR's latest run.

[gadomski]

I'd move this below the local submodules section, and rename as per this suggestion:

Suggested change

	## Related External Projects
	* [stac-fastapi-catalogs-extension](https://github.com/StacLabs/stac-fastapi-catalogs-extension): Multi-tenant virtual catalogs extension for STAC FastAPI deployments, adding a dedicated `/catalogs` registry, scoped catalog routes, and an optional catalog management system for maintaining catalog hierarchies.
	## External third party extensions
	These extensions are hosted in other repositories but can be included in **stac-fastapi** projects. See each extensions' README for instructions on their use.
	* [stac-fastapi-catalogs-extension](https://github.com/StacLabs/stac-fastapi-catalogs-extension): Multi-tenant virtual catalogs extension for STAC FastAPI deployments, adding a dedicated `/catalogs` registry, scoped catalog routes, and an optional catalog management system for maintaining catalog hierarchies.

[gadomski]

It would be easier just to have one place to update when we add other external extension repos.

Suggested change

	#### Third-Party Extensions
	- [stac-fastapi-catalogs-extension](https://github.com/StacLabs/stac-fastapi-catalogs-extension): Multi-tenant virtual catalogs extension for STAC FastAPI deployments. It adds a dedicated `/catalogs` registry, scoped catalog routes, and an optional catalog management system for maintaining catalog hierarchies within one API.
	There are some **stac-fastapi** extensions hosted in external repositories. See [the docs](https://stac-utils.github.io/stac-fastapi/api/stac_fastapi/extensions/third_party/) for a listing.

[jonhealy1]

@gadomski I would rather have some visibility in the main readme if that's ok.

[jonhealy1]

You are basically moving a length of one sentence from the main readme.

[jonhealy1]

Also, if there's no sub heading for third party extensions period, no one is going to notice - I think in the future there will be more stac-fastapi extensions

[jonhealy1]

@gadomski

How would you feel about something like this - no description.

At least we are letting people know that there are third party extensions and they can build one too if they would like. I am still wondering what classifies an extension as 'third-party'. From someone outside the 'community' maybe?

There is an issue here #881 that I think correctly points out that there shouldn't be this concept differentiating third-party and core extensions - they all come from the community.

#### Third-Party Extensions

- [stac-fastapi-catalogs-extension](https://github.com/StacLabs/stac-fastapi-catalogs-extension)

Maybe this would be more appropriate? Would you be ok with something like this?

#### STAC-FastAPI Extensions

- [multi-tenant catalogs extension](https://github.com/StacLabs/stac-fastapi-catalogs-extension)
- [transaction extension]()
- [aggregation extension]()

they could be in alphabetical order

[vincentsarago]

why did we close this ?

[jonhealy1]

@vincentsarago I closed this because I thought we were moving away from classifying some extensions as third-party. Then I started thinking it would be much better to just list all the known stac-fastapi extensions in the readme - we are not asking for a special place in the readme just for our extension ie #898

I created an issue here too: - for better documentation surrounding extensions period #900

I can reopen this if you think this is better

[jonhealy1]

I feel like it's reasonable that people who use stac-fastapi should have good information about the extensions that are out there. Especially if we are going to not allow some extensions to be hosted in the repository - which is reasonable. Extensions hosted externally would generally have better documentation and they can be easily imported.