streamwall
Add dotenv dependency
The command line options are growing verbose, and it would be nice to maintain the same settings while also not having to specify the entire configuration in either the call to the command or by specifying them in the environment
This commit adds a new dependency, dotenv, which allows users to copy the provided sample.env file to ./.env and customize it themselves
Also updates .gitignore to support Jetbrains IDEs and commits the package-lock.json to ensure dependency version consistency
Awesome, thanks @sayhiben! I have been feeling similarly about the proliferation of options. It's time to adopt a more scalable pattern.
FYI I have been configuring these scripts using systemd unit files, and would suggest others running these scripts in production use an equivalent service configuration / supervisor tool.
I've been thinking about switching to yargs, similar to streamwall, so that an optional config file and parameters is supported (here's how streamwall implements it). I have considered using .env files for this, but it seems like yargs provides a few advantages:
- separate config files for multiple configurations
- control over config parsing (I've been thinking about switching to TOML for easy writing)
- param descriptions/
--helpoutput
yargs can also consume environment variables.
Would you be interested in taking this on?
I agree - yargs is likely the right solution. I'm actually in the middle of solving a different challenge with this repo (evaluating live status of profiles instead of discrete videos). This was a quick and dirty implementation meant to provide a stepping stone; if you'd rather move to yargs, I fully support it.
If I'm honest, I don't have bandwidth to handle anything outside of my critical path right now, although normally I'd take you up on the offer to implement. I'm happy to keep this in my fork for the time being if that's preferable to taking on the debt of refactoring it later
On Sun, Jun 28, 2020 at 3:22 PM Max Goodhart [email protected] wrote:
Awesome, thanks @sayhiben https://github.com/sayhiben! I have been feeling similarly about the proliferation of options. It's time to adopt a more scalable pattern.
FYI I have been configuring these scripts using systemd unit files, and would suggest others running these scripts in production use an equivalent service configuration / supervisor tool.
I've been thinking about switching to yargs https://www.npmjs.com/package/yargs, similar to streamwall https://github.com/chromakode/streamwall, so that an optional config file and parameters is supported (here's how streamwall implements it https://github.com/chromakode/streamwall/blob/1087c6855e3e6546d0260d9c260baf71caeebc9c/src/node/index.js#L13-L15). I have considered using .env files for this, but it seems like yargs provides a few advantages:
- separate config files for multiple configurations
- control over config parsing (I've been thinking about switching to TOML for easy writing)
- param descriptions/--help output
yargs can also consume environment variables https://yargs.js.org/docs/#api-envprefix.
Would you be interested in taking this on?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/chromakode/stream-list-updater/pull/1#issuecomment-650829996, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFFX2SAM2RFMDPGW2XC4BLRY67BRANCNFSM4OKW4TJA .