search

c-blake / cligen

Nim library to infer/generate command-line-interfaces / option / argument parsing; Docs at
https://c-blake.github.io/cligen/
ISC License
501 stars 23 forks source link

Add precedence for config/config.toml lookup #143

Closed kaushalmodi closed 4 years ago

kaushalmodi commented 4 years ago

Add a useful error message if config.toml is found, but the project is not compiled with parsetoml.

Ref: https://github.com/c-blake/cligen/pull/141#issuecomment-624030900

c-blake commented 4 years ago

I'm not sure we want to do this. I don't know how rigid in the TOML world in general always having .toml extensions are. Also, cligen may be a leaf dependency of different packages...Some which compile with -d:cgCfgToml and some which do not. Then a user might have a "stray" config.toml around from one but maybe doesn't use it for others, etc. It's kind of a complicated situation.

c-blake commented 4 years ago

We might even need $CLIGEN to have $PATH like search semantics with : separators even.

c-blake commented 4 years ago

And if we ever do both parsers in one program we need to decide on/have the user decide on priority.

kaushalmodi commented 4 years ago

I don't know how rigid in the TOML world in general always having .toml extensions are

I can say that it's pretty rigid and consistent. I have using the config.toml's in Hugo , Netlify and Gitlab Runner.

Then a user might have a "stray" config.toml around from one but maybe doesn't use it for others, etc. It's kind of a complicated situation.

Hmm. I agree (kindof.. because I would think that users will gravitate towards one format or the other).

And if we ever do both parsers in one program we need to decide on/have the user decide on priority.

I think that's unnecessary complexity. If you choose just one precedence and document it, users can then choose which format config to keep/maintain. For example, I converted your example config to config.toml and will keep maintaining that.

So for more folks, the precedence wouldn't matter much as long as it's fixed and documented.

c-blake commented 4 years ago

It may not be..exactly, CL user choice. The CLI util author may turn on -d:cgCfgToml. So, if a user justs nimble install x and nimble install y they may need both formats at the same time. Then either mode warning about the other would be wrong. But then, much of the time the CL user may be the one doing -d:cgCfgToml. So, it's kind of tricky. I think we should just leave it as-is now where neither parser knows about the other's existence. At least for a while.

kaushalmodi commented 4 years ago

OK, I will close this PR then.