not a drop-in replacement

[namsral]

not a drop-in replacement

[namsral]

Software is opinionated, namsral/flag is no exception.

[namsral]

Could you post your code because in my tests your described scenario works.

[skrassiev]

Ok, I inaccurately described the issue:

Main package imports "github.com/namsral/flag" and calls flag.Parse()
Main package imports a third-party "someotherpackage".
someotherpackage package imports just standard "flag" and declares some flags.

github.com/namsral/flag.Parse() would not see flags, declared through standard flag package in someotherpackage.

That's definitely a shortcoming as you don't have control over third-parties.

[namsral]

The flag package is meant to be used by program developers, not library developers. Third party packages should not depend on the flag package. Package variables should be set via exported variables, functions, the init function, etc.

[skrassiev]

there is no limitation on where the flag package should be used from.

[namsral]

I beg to differ; as a program developer I would like to have the final say in building the user interface instead of the library developer.

Can you provide me with example where it would be an advantage to include the flag package in a library.

[sundarv85]

Hello, I’m also facing a similar issue. But I cannot get my head around on why this happens.

Following is what I do:

• I’m using goji's -- goji.Serve()
• I have parameter db-address

When I’m running with namsral/flag - I get the error

flag provided but not defined: -db-address
Usage of ./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.

This error comes from https://github.com/zenazn/goji/blob/master/bind/bind.go

When I use the golang's default flag, then the error is gone.

Any reason why this goes away when I use default flags.

[namsral]

Within the goji package replace the flag import with github.com/namsral/flag.

[ivucica]

Replacing flag is not trivially doable in every situation. For example, I don't believe I can do it in github.com/golang/glog without forking that package.

[andrejmaya]

@namsral: I want to use glog in my main go program. When I pass -logtostderr=true -v=2 to my main go app, I get a flag provided but not defined: -logtostderr error message back. I tried to export LOGTOSTDERR=true with no luck.

[namsral]

It's bad practice to parse command line options in a library. Please see a previous comment on a similar issue.

[ivucica]

Real life libraries, including aforementioned glog provided in golang organization on GitHub, do it. It may be bad practice, but is done, and dismissing this use case should be done with care.

On Tue 11 Jul 2017 at 21:06, Lars Wiegman ***@***.***> wrote: It's bad practice to parse command line options in a library. Please see a previous comment <#3 (comment)> on a similar issue. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAdJnLGCaLfq37LQyiTO3mdftD8YsA2mks5sM9XYgaJpZM4DX83g> .

-- Sent from Gmail Mobile on iPad