sbtc-developer-release
sbtc-developer-release copied to clipboard
Devenv util script don't work if romeo is not running in a container
Expected Behavior
- I comment out the
sbtc
container in the docker compose file (I can't have it running when working on local romeo) - I run devenv
- util commands continue working
Actual Behavior
Commands don't work as they expect the sbtc container to be running to use sbtc-cli inside it.
Steps to Reproduce
- Comment out the sbtc part of the docker compose file
- Run devenv
- Try running util commands
I think we need to be a bit discerning about what devenv features we support - when we're having all these different options we make the backend of devenv increasingly complicated. After the hackathon we should discuss what features we really need and what we don't.
I could see an argument for removing romeo from the container entirely and expecting romeo
to be running locally. @radicleart, @friedger does that match better to the workflow you've been doing to test?
@EmbeddedAndroid since you're the devenv visionary I'm curious what your thoughts are.
Though, @stjepangolemac, I wouldn't consider this a bug because we know it doesn't do this.
I could see an argument for removing romeo from the container entirely and expecting
romeo
to be running locally. @radicleart, @friedger does that match better to the workflow you've been doing to test?
Hey yes for me the main issue is support in Leather for regtest bitcoin addresses - this is a dependency for the bridge on devnet. Due to this I'm running Romeo, Bridge UI and Bridge API standalone on testnet.
@AshtonStephens Let's build a stable product for the hackathon.
For development of romeo, the scripts using my local sbtc binary were helpful. Maybe we need to duplicate them.
We can add a flag to execute on local binaries or default to a service.
What are util scripts anyway? We have a problem if devenv
is not helpful for development. Are we stretching devenv too much? It could be beneficial to redefine what devenv
is and is not.
I would argue that devenv
is a big success, and people will want features tailored to their needs. Would it be helpful to provide different devenv
tiers? This way, we can support core features while letting devs customize their local dev experience further from a solid base. Downing services manually has been problematic due to service dependencies. Putting more options on up.sh
and down.sh
to spin a service subset may be worthwhile.
Utils scripts can have the former flag to choose a running a script in devenv or locally. This allows the user to target devenv
or a local resource regardless of the devenv
services subset running.
Naïve example of devenv tiers (service subsets) :
- bitcoind
- bitcoind + stacks
- bitcoind + stacks + sbtc
- ...
Each tier should have a clear goal/scope.
- stacks-node development
- Romeo development + stacks integration
- leather wallet integration + Romeo integration
- e-2-e integration
I could see an argument for removing romeo from the container entirely and expecting romeo to be running locally
This sounds very reasonable for me, and the same might apply to the bridge related containers post hackaton. The devenv was originally envisioned to be run as infra, and everything else would be external. I understand we might want to bundle more things together for the hackaton, so unbundling it like this can wait.
I think we would be useful to look into is: https://docs.docker.com/compose/multiple-compose-files/extends/ and https://docs.docker.com/compose/compose-file/10-fragments/
I think this would give us the flexible to on the fly configure the services that needs to be started.
Wow, I didn't know YAML supported all these kinds of things mentioned in the fragments docs 😅
Cool but also cumbersome in the same time!