Can't have multiple instances of `bud run` at the same time

[012e]

Reproduce

1. Create 2 different project bud create --module=a a and bud create --module=b b
2. bud run in project a, bud run --listen 3001 in project b
3. Error with project b

   
   | Listening on http://127.0.0.1:3001                                                    
   | listen tcp 127.0.0.1:35729: bind: address already in use

[matthewmueller]

Ah, good point! This is a known TODO in the codebase, for example:

https://github.com/livebud/bud/blob/6485405ec244c8df90d7a6acb6aa36cd77f7d9ca/internal/entrypoint/list.go#L161

I haven't had a chance yet to thread the configuration through all the layers. If you do a search for :35729, you should see a few spots where this should be configurable.

I was thinking you could do the following:

• --hot=false to disable hot-reloading
• --hot=:3500 to enable hot-reloading on port :3500

I think commander even has a way to do custom flags. I feel like I ran into a problem trying this though, but I can't remember.

The way I was thinking about this so far is:

• bud run: defaults to enabled hot reloading on address :0 (any free port). The chosen free port gets threaded through the configuration.
  • Overridable by using --hot=:3500 or perhaps --listen-hot=:3500.
  • If we go with --listen-hot, I'm not sure there's a need for --hot anymore.
• bud build: defaults to hot=false, but can be turned on with the flags above.

[matthewmueller]

Calling out another challenge which is that the response package hardcodes this value:

https://github.com/livebud/bud/blob/5a45c5e67051a3e591a718758970e3de9eae2a4f/framework/controller/controllerrt/response/response.go#L158

That internal package is quite old and is need of an update. Ideally the generated controller creates a response struct that can contain configuration like this.

[sourcec0de]

Hey @matthewmueller digging into this thread a bit. :wave:
What do you think about selecting an ephemeral port here? This seems like a good injection point here.

[matthewmueller]

Hey @sourcec0de! I think that would work, but it might be easier to pass through the response itself: https://github.com/livebud/bud/blob/19a27ce387c109afa7766fd6e494da015b39f929/framework/controller/controller.gotext#L118

You could thread it to that template by passing the listener or the address through the filesystem function to the controller generator: https://github.com/livebud/bud/blob/19a27ce387c109afa7766fd6e494da015b39f929/internal/cli/run/run.go#L90-L100

This would be somewhat messy. I think adding the bud address to framework.Flag config would be the best bet for now though. Right now Bud seems to be missing some internal configuration package that can be built up over time, passed around, and compute values from other config.

Sidenote on the response package: This stateless response package will be replaced once controllers are revisited. Originally I planned to make it a public helper library, but we'll take advantage of generics (e.g. web.Response[IndexOut]) to provide more control over responses in the future, so this package being meant for public consumption doesn't make sense anymore.