Improve bud run's --port flag

[matthewmueller]

Problem

There's been justified confusion over the --port flag.

The --port flag is currently overloaded to support passing a host, port and path. You can find all the possibilities in this test file, but here's the gist:

• --port=5000 maps to http://127.0.0.1:5000
• --port=:5000 maps to http://127.0.0.1:5000
• --port=127.0.0.1 maps to http://127.0.0.1:3000
• --port=localhost maps to http://localhost:3000
• --port=/tmp.sock maps to http:///tmp.sock
• --port=w.x.y.z maps to http://w.x.y.z:3000/
• --port=w.x.y.z:8080 maps to http://w.x.y.z:8080/

Original Goals

• Support adjusting the port, host and using unix domain sockets (currently used by the tests)
• Unify the flags into one input

Personal Opinion

I completely agree that --port is confusing to say the least, but my preference would be to keep the unified input and change the name. The reason is that separate flags for host, port and unix domain socket path get to be a lot.

Potential Solutions

One idea that came up in #35 was to use --bind. While I know this is the correct term for the action (e.g. binding to a port), I'm not in love with the term bind because it reminds me of too many other things:

• Data binding (e.g. https://github.com/mholt/binding)
• Binding context (e.g. fn.bind(this))

Can we come up with a simple, yet better keyword? Maybe --url or --address? Any other ideas? Or do you think --bind is the right call?

✅ Update May 31, 2022

Decided to rename to --listen, which is now in main. Examples:

• --listen=5000 maps to http://127.0.0.1:5000
• --listen=:5000 maps to http://127.0.0.1:5000
• --listen=127.0.0.1 maps to http://127.0.0.1:3000
• --listen=localhost maps to http://localhost:3000
• --listen=/tmp.sock maps to http:///tmp.sock
• --listen=w.x.y.z maps to http://w.x.y.z:3000/
• --listen=w.x.y.z:8080 maps to http://w.x.y.z:8080/

[codenoid]

If it's need to be two param, I strongly suggest to use --host and --port and combine them with net.JoinHostPort

[matthewmueller]

Yep. I think if it's just those two flags, that would be acceptable, but I'm not sure how you'd support unix domain socket paths with only those flags.

[codenoid]

IMO, I would prefer --bind, some might --bind-addr but's it's too long

bud run --bind-addr 127.0.0.1:3000 // too long
bud run --bind 127.0.0.1:3000 // just _ok_
bud run --url 127.0.0.1:4000 // but we also allow unix domain socket paths
bud run --address 127.0.0.1:4000  // ummm, wdyt?

bud run --listen 127.0.0.1:3000

[alecthomas]

I think --bind or --listen are the two most common terms.

[syke99]

I agree, I’d say --listen would be the best alternative for a single flag

[matthewmueller]

Currently leaning towards --listen, despite --bind being shorter.

Will give it a day to see if anyone else brings something to the table, then make a call.

[batara666]

--listen are eye-friendy tho

[matthewmueller]

Going with --listen, it's in main now

[tmichaud]

Recommend that initial problem include an example of setting the ip address.
Example:
--port=w.x.y.z maps to http://w.x.y.z:3000
--port=w.x.y.z:8080 maps to http://w.x.y.z:8080

I do my coding on a headless go box and for some reason it wasn't picking up the 127.0.0.1 when I was hitting it remotely. (Weird)

[matthewmueller]

Just added your two examples. Did --port=w.x.y.z work for you though?

[tmichaud]

Just added your two examples. Did --port=w.x.y.z work for you though?

Absolutely. Worked great.
Going to pull the new version tomorrow.

[matthewmueller]

It'd be in main, not in a release yet.