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

Add a standardized interface to pass configuration parameters as CLI arguments #26

Open
Duckwhale opened this issue Oct 22, 2021 · 1 comment

Comments

@Duckwhale
Copy link
Member

Duckwhale commented Oct 22, 2021

The first argument is always the name of the user script, but the rest should be reserved for optional configuration options.

Instead of going with the traditional "let's add a million switches with single-letter abbreviations that no one understands", I want to explore a slightly different design: Similar to CVars used in many C(++)/Lua programs, the options should be provided in CVAR=value form. This has some benefits, as well as drawbacks:

  • Easier to parse, can simply assign the value to a global configuration variable OR use a CVar API (see WOW client)
  • Easy to understand since the format is always the same and variable names can be much longer
  • No issues with ordering of values; each setting is simply provided as a new CLI argument (separated by space)
  • One could easily pipe it from regular Lua configuration files (subshell and cat, plus replace newlines with space if newline shouldn't be supported as a separator)
  • If there is just one second argument consisting of multiple settings, separated by newlines (piped in), it can be executed as Lua code (will set the globals), and if there is multiple... can also be executed as Lua code (individual chunks that set one global per)

The only drawback I see is that it might go against the tradition that many (especially *nix users) may have come to expect. But then they'll be used to looking stuff up anyway, so they might as well look up the CVar names? Not sure if that's a big deal, but it doesn't seem too bad for me and it's consistent with a Lua-centric UX - if you understand basic Lua you'd also understand this.

Some examples:

  • evo myScript.lua ENABLE_PROFILING=true LOG_INFO=true LOG_DEBUG=true (names can likely be improved)
  • evo myScript.lua $(cat debugConfig.lua)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Roadmap
Current Major Version (0.x)
Timeline
Soon™
Development

No branches or pull requests

1 participant