bind forces the user to have a -bind flag about goji HOT 11 CLOSED

By override do you mean "specify the port in the application itself" or
"use the flag in my own package"?

On Sunday, July 20, 2014, Jesús García Crespo [email protected]
wrote:

bind is fantastic, but it defines a -bind cli flag even when you are not
making use of it. I'm aware that people out there may be relying on that
specific behaviour but it would be nice to have a mechanism to override it,
any ideas?

—
Reply to this email directly or view it on GitHub
#47.

from goji.

I meant the former, in my particular case I just don't want to use -bind right now. But I guess redefinition of the flag wouldn't be possible neither.

from goji.

Confirmed, it panics! See http://golang.org/src/pkg/flag/flag.go?s=22344:22405#L661.

from goji.

You can use https://godoc.org/github.com/zenazn/goji/graceful#ListenAndServe to
specify a listening port.

i.e.

r := web.New()
r.Use(middleware.Recoverer)
// etc...
r.Get("/", ShowIndex)

graceful.ListenAndServe(":8000", r)

This is exactly what I do.

On Sunday, July 20, 2014, Jesús García Crespo [email protected]
wrote:

I meant the former, in my particular case I just don't want to use -bind
right now. But I guess redefinition of the flag wouldn't be possible
neither.

—
Reply to this email directly or view it on GitHub
#47 (comment).

from goji.

Yeah, I'm doing something similar. I'm assuming you also make use of the -bind flag. I think it's a bit too invasive... e.g. let's say that you don't want to provide that option in your command line tool because your configuration loading mechanism takes care of the address to bind on somewhere else.

$ go run server.go -help
Usage of /h/u/g/bin/server
  -bind=":8000": Address to bind on. If this value has a colon, as in ":8000" or
        "127.0.0.1:9001", it will be treated as a TCP address. If it
        begins with a "/" or a ".", it will be treated as a path to a
        UNIX socket. If it begins with the string "fd@", as in "fd@3",
        it will be treated as a file descriptor (useful for use with
        systemd, for instance). If it begins with the string "einhorn@",
        as in "einhorn@0", the corresponding einhorn socket will be
        used. If an option is not explicitly passed, the implementation
        will automatically select among "einhorn@0" (Einhorn), "fd@3"
        (systemd), and ":8000" (fallback) based on its environment.

from goji.

I don't use the -bind flag myself.

Using graceful.ListenAndServe to explicitly specify a port does not
configure the -bind flag (it's only provided when you use the top-level
Goji package):

./wwg2 -help
Usage of ./wwg2:
-createadmin=false: Create a new administrative user
-createdb=false: Create the database schema.
-email="": Email address
-name="": Full name

Notice that -bind isn't an available option.

On Sunday, July 20, 2014, Jesús García Crespo [email protected]
wrote:

Yeah, I'm doing something similar. I'm assuming you also make use of the `
-bind flag. I think it's a bit too intrusive... e.g. let's say that you
don't want to have that option in your command line because your
configuration loading mechanism is different.

$ go run server.go -help
Usage of /h/u/g/bin/server
-bind=":8000": Address to bind on. If this value has a colon, as in ":8000" or
"127.0.0.1:9001", it will be treated as a TCP address. If it
begins with a "/" or a ".", it will be treated as a path to a
UNIX socket. If it begins with the string "fd@", as in "fd@3",
it will be treated as a file descriptor (useful for use with
systemd, for instance). If it begins with the string "einhorn@",
as in "einhorn@0", the corresponding einhorn socket will be
used. If an option is not explicitly passed, the implementation
will automatically select among "einhorn@0" (Einhorn), "fd@3"
(systemd), and ":8000" (fallback) based on its environment.

—
Reply to this email directly or view it on GitHub
#47 (comment).

from goji.

Oh, I see! I was importing goji because of DefaultMux but I guess I can just build my own Mux object. Thank you!

Should I close this issue?

from goji.

So like elithrar mentioned, the project is structured in such a way that using the top-level goji package gives you a really nice out-of-box experience with reasonable defaults, and the sub-projects provide more API flexibility for people who have either specific needs or simply don't like the defaults I've chosen.

I've considered making bind not install the flag by default, instead exposing a function that adds the flag for you (that the top-level goji would call, similar to what we do now for graceful.HandleSignals()). The primary motivation here would be that bind has grown some moderately interesting logic for parsing "bind strings," and it'd be a pity if people had to inline that logic just to avoid the global flag pollution. I think this would allow you to do what you want to do? (i.e., you'd still need to create your own mux, etc. etc., but at least you'd be able to use the same bind string syntax)

from goji.

I agree. I think that the current project structure is brilliant.

from goji.

Alright, bind grew a bind.WithFlag() which does what you want :)

from goji.

I like it.

from goji.