File paths and altsrc

[VMitov]

When having a flag representing file path and using alternative sources if becomes hard to figure out what the file path is relative to.

• if you're running from the same folder the config file is - cmd current dir is the same as the config file dir, so it doesn't matter
• if you're running from different folder and taking the option from the file - path should be treated as relative to the config file
• if you're running from different folder and taking the option from the cmd - path should be treated as relative to the folder you're running the cmd from

I'm using v2 btw.

[jszwedko]

👍 I agree with these three assertions, can you qualify which are not currently met?

[VMitov]

It depends on the implementation. In my case the last one is failing. If there is a way to find out what is the source of a flag - I would easily fix it.

[VMitov]

I solved it with custom PathFlag. Do you fancy PR? The only caveat is - how I know the directory where the config file is in the PathFlag ApplyInputSourceValue?

[jszwedko]

You should be able to get the current working directory via os.Getwd. PRs definitely welcome 😄

[VMitov]

What I mean is that in ApplyInputSourceValue don't have the flag name for the configuration file.

[VMitov]

And that's what I mean :) https://github.com/urfave/cli/pull/670/files#diff-b409136834e66f5a239c3d6ca4df876dR255 . How you think it will be best to fix that? Put it in the context may be?

#670

[coilysiren]

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