Break out STAC Ingestor codebase into separate repo

[alukach]

Currently, we store the STAC Ingestor codebase alongside the STAC Ingestor CDK construct. This means that if a user wants to customize the STAC Ingestor, they need to copy/replicate the STAC Ingestor codebase into a separate repo, customize it, and then recreate the logic around the StacIngestor construct. A better scenario would be to be able to provide the construct an argument that represents a pip-friendly location the codebase can be installed from. I am not certain of the best way to do this.

First pass at a solution

Currently, we are using the PythonFunction construct which requires that a user pass in a directory where either a Pipfile.lock, poetry.lock, or requirements.txt file can be found (source).

It seems like something along the lines of the following may work: Create a custom construct that took in the identifier of an installable module, wrote that to a requirements.txt file, and then passed the path of that requirements.txt file to the Python Lambda to be built. I'm not sure how we could support the customization of the entry and handler arguments...

[sharkinsspatial]

@alukach I might have some time available to look at this next week if you want to tackle this. I might be missing something but would a simpler approach be just to avoid PythonFunction and force users to pass a deployment package via fromAsset. If they wanted to build the deployment package dynamically as part of their own CDK code and inject it into the construct they could.

[vincentsarago]

👋 if no-one already did this, I could work on it.

any objection about using pgstac-ingestor name? also are we fine having this in devseed organisation for now (we could put in in stac-utils if we wanted)?

[vincentsarago]

I started something over https://github.com/developmentseed/pgstac-ingestor

[emileten]

Maybe we could try to solve this #9 at the same time?

[vincentsarago]

@emileten I think this is fixed in developmentseed/pgstac-ingestor#2 🤷‍♂️