Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flag precedence failure for config file (v1) #706

Closed
ragecryx opened this issue Jan 30, 2018 · 7 comments
Closed

Flag precedence failure for config file (v1) #706

ragecryx opened this issue Jan 30, 2018 · 7 comments
Labels
help wanted please help if you can! kind/bug describes or fixes a bug

Comments

@ragecryx
Copy link

ragecryx commented Jan 30, 2018

I have a setup as described in Values from alternate input sources (YAML, TOML, and others)

I try to run the executable with command line arguments, like:

tool dostuff --host my.super.host

config file doesn't exist and I don't provide one and the execution stops instead of relying on the provided arguments. The failure seems to happen on command.go:197 (caused by altsrc/flag.go:57 probably) where there is no YAML file to open thus it prints help and exits.

Is there any workaround for this? Is it solved in v2?

@jszwedko
Copy link
Contributor

jszwedko commented Feb 2, 2018

Hi @ragecryx ,

I agree, the file shouldn't be required; it just shouldn't be loaded if it doesn't exist (at least as optional behavior).

For now you can work around it by checking for file existence before calling altsrc.NewYamlSourceFromFlagFunc, but I'll mark this as an issue.

PRs welcome for this.

Thanks!

@jszwedko jszwedko added kind/bug describes or fixes a bug help wanted please help if you can! labels Feb 2, 2018
@ragecryx
Copy link
Author

ragecryx commented Feb 3, 2018

@jszwedko I was willing to write a fix but the Before hook seems generic enough that skipping the failure check will break someone else's code. This should be handled on altsrc level, like NewYamlSourceFromFlagFunc succeeding if file was not found or provided?

EDIT:
Also the fix should target v1 or v2 or both?

@jszwedko
Copy link
Contributor

Yeah, I think handling this within altsrc itself seems reasonable.

I'd target v1 for now, it can be merged up into v2.

Thanks for taking a look at this!

@tonglil
Copy link

tonglil commented Feb 12, 2018

How do you check that the fix exists if you haven't parsed the flags yet?

For example, the file flag is --config, you don't know if the user passed abc.yaml or xyz.toml until you parse the flag for --config. By then, the rest of the flags will have been parsed too.

@jszwedko
Copy link
Contributor

@tonglil since altsrc is implemented as a Before function you can check the parsed flag first (the flags will have been parsed by the time it runs).

Something like:

app.Before = func(c *cli.Context) error {
    if _, err := os.Stat(c.String("load")); os.IsNotExist(err) {
        return ...
    }

   return altsrc.NewYamlSourceFromFlagFunc(flags, c.String("load"))(c)
}

@ragecryx
Copy link
Author

I made this fix #713 , I tested it in my project and it works with or without config file but I feel bad having the error not logged anywhere. Any tips about that?

@meatballhat meatballhat self-assigned this Feb 25, 2018
@asahasrabuddhe asahasrabuddhe self-assigned this Aug 5, 2019
@coilysiren
Copy link
Member

Hiya! There's a known issue with the current implementation of the CLI, where altsrc is generally clunky and poorly documented. My current idea is that I'm going to move all of the altsrc functionality into the main package in some way, and that's how all of the "altsrc is weird and different???" issues people are having will get resolved. I'm tracking that work here => #833

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted please help if you can! kind/bug describes or fixes a bug
Projects
None yet
Development

No branches or pull requests

6 participants