Enable abra to include utility recipes #488

New Issue

iexos · 2023-09-01T13:37:16Z

iexos commented

2023-09-01 13:37:16 +00:00

Its currently not possible to reuse solutions made in one recipe in others without copy-pasting. I would love to reuse parts without having to maintain them seperately. My current use case would be including postgres with major version upgrades. A quick idea to solve this:

have utility recipes, e.g. postgres
import via compose include
pin utility recipe version as git submodule
- could also just use release tags, but seems more fragile to me

Would need to implement in abra:

git submodule handling
a reasonable and transparent way for recipe maintainers to upgrade included utility recipes

I am unsure if its worth it the additional complexity right now, on the other hand it could make creating and maintaining recipes with the usual databases, caches etc easier.

Its currently not possible to reuse solutions made in one recipe in others without copy-pasting. I would love to reuse parts without having to maintain them seperately. My current use case would be including [postgres with major version upgrades](https://git.coopcloud.tech/coop-cloud/outline/pulls/15). A quick idea to solve this: - have utility recipes, e.g. postgres - import via [compose `include`](https://docs.docker.com/compose/compose-file/14-include/) - pin utility recipe version as git submodule - could also just use release tags, but seems more fragile to me Would need to implement in abra: - git submodule handling - a reasonable and transparent way for recipe maintainers to upgrade included utility recipes I am unsure if its worth it the additional complexity right now, on the other hand it could make creating and maintaining recipes with the usual databases, caches etc easier.

iexos added the

enhancement

label 2023-09-01 13:37:16 +00:00

decentral1se commented

2023-09-01 14:09:37 +00:00

Good point, it would be great to improve here! But ouch, I'd not wish implementing git submodule handling in abra on my worst enemies 😆 I think a simple way to support this would be to agree on a convention (e.g. ~/.abra/scripts/abra.sh or whatever) that is abra sees, it can source before running stuff?

Good point, it would be great to improve here! But ouch, I'd not wish implementing git submodule handling in `abra` on my worst enemies 😆 I think a simple way to support this would be to agree on a convention (e.g. `~/.abra/scripts/abra.sh` or whatever) that is `abra` sees, it can source before running stuff?

decentral1se removed the

enhancement

label 2023-09-01 14:09:53 +00:00

iexos commented

2023-09-01 14:41:32 +00:00

Can you elaborate on how that would work?

I agree that submodules are a pain, they just seem to fit the purpose quite well. I think its important to somehow prevent including the wrong version (looking into it, git submodules might not even be good at that 🤦).

Can you elaborate on how that would work? I agree that submodules are a pain, they just seem to fit the purpose quite well. I think its important to somehow prevent including the wrong version (looking into it, git submodules might not even be good at that 🤦).

decentral1se added the

abra

enhancement

labels 2023-09-05 15:47:18 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/organising#488