-
Notifications
You must be signed in to change notification settings - Fork 105
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove backend repos #555
Remove backend repos #555
Conversation
941a56d
to
2b64a72
Compare
I'm noticing a few spots in which old references exist in the docs. Going to list them here in case we want them updated prior to merging:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The downstream repos are working as expected. There's a minor typo I caught in the README, but otherwise LGTM
Did you re-build the docs? I just did, and I'm not seeing any (all?) of those examples. The API docs are auto-generated. I do see some dangling references in |
I think you're right. I was misinterpreting the results of that grep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These changes look good to me. I think there's one more file, scripts/wait-for-it.sh
that is no longer used and could also be deleted.
As you mentioned in the PR, without a default backend, it's a little difficult to run/test changes without coordinating with a new backend repo. Do you have general (or specific) ideas about what the best dev workflow for updating this project with a backend? As a proof of concept, I tried mimicking a git submodule approach: cloning stac-fastapi
into a gitignored subdirectory of stac-fastapi-pgstac
and modifying the dockerfile there to do an editable install of these packages. Seemed a bit clumsy but should work. Perhaps when we've got a good flow we can update the development documentation here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a question about the docs.
Agreed.
In the past, I've used my IDE's "workspace" concept, coupled with a virtual environment that has both packages installed in editable mode, to work on two repos at once. I think a similar approach could work here. That's relies more on a non-Docker development environment, so your submodule approach also seems good. |
Related Issue(s):
Description:
No functional code changes. Removes the two backends, they live on their own now:
It'd be nice to have a in-memory backend that we could use to exercise the API w/o a database, but that's a pretty significant lift. Something for the future, perhaps.
This is such a major change to the infrastructure (not the code) that I'd like to get at least two approving reviews on it.
PR Checklist:
pre-commit
hooks pass locallymake test
)make docs
)