Looks good to me apart from the one point regarding mounting files.
Why do we create separate branches per mode: mocknet/testnet/mainnet + persist / non-persist? We could also split it over multiple compose files.
docker-compose -f mainnet.yaml up
docker-compose -f testnet.yaml up
Or even layer them:
docker-compose -f mainnet.yaml -f persist.yaml up
Etc. Let me know what you think. I can make those changes. We can define separate envs or another context switch to keep the same level of operability without having to manage a bunch of branches.
Definitely could do that - but that would also require specific changes to the .env files.
You're kind of getting into the whole reason this repo exists - it wasn't originally supposed to do what it's used for today. it was designed literally for local mocknet dev work. it had to be repurposed quickly to provide mainnet features.
the next update, perhaps we can work together on consolidating. the idea of relying on the end-user to use the correct files on startup i think wouldn't be the best, but pehaps a wrapper could make this easier, i.e. ./launch testnet
I think a wrapper here is the way to go - the main sticking point would be the docker-compose setup. ideally i'd like to keep a single docker-compose file, but that could prove to be a challenge due to the use of the network name (used for DNS between containers). I think something along the lines of creating a template for the docker-compose, where the wrapper will perform the envsubst so the correct network is created/launched. something along the lines of this:
Not impossible i don't think -> i'm kicking around a few ideas.
Definitely could do that - but that would also require specific changes to the .env files. You're kind of getting into the whole reason this repo exists - it wasn't originally supposed to do what it's used for today. it was designed literally for local mocknet dev work. it had to be repurposed quickly to provide mainnet features.
the next update, perhaps we can work together on consolidating. the idea of relying on the end-user to use the correct files on startup i think wouldn't be the best, but pehaps a wrapper could make this easier, i.e.
./launch testnetOriginally posted by @wileyj in https://github.com/blockstack/stacks-local-dev/issues/30#issuecomment-827700370
@MarvinJanssen
I think a wrapper here is the way to go - the main sticking point would be the docker-compose setup. ideally i'd like to keep a single docker-compose file, but that could prove to be a challenge due to the use of the network name (used for DNS between containers). I think something along the lines of creating a template for the docker-compose, where the wrapper will perform the envsubst so the correct network is created/launched. something along the lines of this:
Not impossible i don't think -> i'm kicking around a few ideas.