Split backends into independent repos

[geospatial-jeff]

Discussion started here: #409 (comment).

Including backends in this repo was convenient when stac-fastapi was first created but the pros are now outweighed by the cons.

Migration plan:

1. Merge all open PRs.
2. Release a new version, this will be the last version with a monorepo.
3. Create two new repos in stac-utils org, one for each backend.
4. Copy backend submodules over to new repos.
5. Merge the api, extensions, and types submodules into a single stac-fastapi package, keep import paths the same to avoid breaking.
6. Cut over to the new stac-fastapi package in the backend repos.
7. Test / validate backend repos before we merge all of the code.
8. Move backend specific issues to the appropriate repo.

[duckontheweb]

I'm a huge +1 for this and I'm happy to help with part of it if you want.

5. Merge the api, extensions, and types submodules into a single stac-fastapi package, keep import paths the same to avoid breaking.

I'm a big fan of this. I've been using poetry a bunch lately, but it doesn't support installing from GitHub subdirectories, which has been a blocker for trying to install the latest unstable version of this library. This would solve that issue.

[geospatial-jeff]

I'm a huge +1 for this and I'm happy to help with part of it if you want.

That would be great! I'm going to start getting all of the open PRs resolved, not exactly sure how long that will take. But I imagine it will be easier to merge all the packages once this is done. It looks like the relevant PRs to api/extensions/types modules are:

• Add support for APIRouter prefix #429
• Remove duplicated code #428
• Fix media type for queryables endpoints #421
• Update filter conformance classes #417
• Fix/forwarding headers #415
• Enable runtime CORS configuration via environment variables #341

[duckontheweb]

Sounds good. I can create new repos for the backends (stac-fastapi-sqlalchemy and stac-fastapi-pgstac). We will probably want to resolve the following PRs before we port the code over since they all make changes to one or both of the backends:

• Use collection_id path parameter Items Transactions endpoints #425
• Return added Item/Collection in Transactions response #424
• Fix joplin pgstac #418

[geospatial-jeff]

@duckontheweb I can start moving code into stac-fastapi-sqlalchemy. I'll try to keep the repo structure as similar as possible.

[duckontheweb]

@duckontheweb I can start moving code into stac-fastapi-sqlalchemy. I'll try to keep the repo structure as similar as possible.

Sounds good. I’m wondering if we should actually fetch from this repo into those ones in order to preserve the Git history. I think setting up this repo as a remote and then doing a “git reset —hard” to the master branch of this repo would do the trick

[duckontheweb]

I'm going to move the pgstac backend over to stac-fastapi-pgstac and preserve the Git history. I'll try to keep the repo structure as similar as possible, too.

I will also set up the default branch for that repo to be main instead of master. We may want to consider making the same change in stac-fastapi-sqlalchemy and in this repo while we are doing this overhaul.

@geospatial-jeff Let me know if you want me to work on consolidating this repo into a single Python package.

[captaincoordinates]

is it part of the plan to release 2.4.0 after the outstanding PRs are merged, and before the repo is broken apart? There seem to be a lot of unpublished changes against the current repo structure.

[duckontheweb]

is it part of the plan to release 2.4.0 after the outstanding PRs are merged, and before the repo is broken apart? There seem to be a lot of unpublished changes against the current repo structure.

I think this would probably be a good idea. The intention is to not make any breaking changes as part of the new repo structure, but just to be safe we might want to cut a release first.

[geospatial-jeff]

Yes I can create a release after #441 is merged.

[duckontheweb]

I ported the code to stac-utils/stac-fastapi-pgstac and opened stac-utils/stac-fastapi-pgstac#1 to start trimming that down to just the PgSTAC backend.

[geospatial-jeff]

I'll have the 2.4.0 release out sometime tomorrow.