cyanreg
[Feature request] Configuration file support
First of all, I want to thank you for providing an excellent tool that has now become my de facto replacement for ripit. It's fast, it's good, and it does everything I want. Well, almost, or I wouldn't be making RFIs :-)
It would be nice if Cyanrip were to support configuration files - preferably the usual cascade of them in /etc > ~/ > $PWD. Right now I've configured my defaults using an alias, but that's comparatively more clunky to manage as well as not being very intuitive.
The options for cyanrip are simple enough that I think a config file is unnecessary and would bring a lot of baggage (it would need to have a maintained and documented format, as cyanrip options change the configs of users would get stale and break or else there would need to be some sort of migration scheme or we'd just be forced to never change the options, etc.).
What I would do personally and what I recommend is to create a wrapper script that applies your preferred default options and then passes through any arguments it gets. For example, if you wanted to use -Z 1 by default then your wrapper would look something like this:
#!/usr/bin/env bash
CYANRIP=/path/to/cyanrip
"$CYANRIP" -Z 1 "$@"
The "$@" is what allows this to pass through arguments the wrapper gets on to cyanrip.
Put this in a directory that you add to your $PATH such as $HOME/bin or $HOME/scripts. If you put the wrapper in a directory that's in your $PATH before the directory where cyanrip lives then you can even name the wrapper cyanrip and use it that way on the command line. Or you could set a cyanrip alias that points to your wrapper.
This approach also gives you the flexibility to do things like run your own commands before and after cyanrip or modify the arguments that get sent to cyanrip.
What you just described is essentially an executable configuration file, which is generally considered a Bad Idea for largely the same reasons you bring against a proper configuration file :-) It is, in fact, what I do now for lack of a proper config file - and I opened this FR in hopes of getting rid of that clunky script.
A config file doesn't really bring nearly as much baggage as you seem to think. Yes, you need to document the format - which typically goes "all the cli options exactly as specified, one per line" :-) Modifying that file when options change is up to the user, exactly the same as a script.
Implementing config isn't particularly complex either; there are plenty of libraries that read INI or whatever format and transform it into an array of options that looks just like an array of cli options.
The options for cyanrip are simple enough that I think a config file is unnecessary and would bring a lot of baggage (it would need to have a maintained and documented format, as cyanrip options change the configs of users would get stale and break or else there would need to be some sort of migration scheme or we'd just be forced to never change the options, etc.).
It would not bring a lot of baggage, as maintenance and documentation wouldn't require more than what is already necessary for CLI options seeing how this is more or less a mirror of that. The code parsing a config would be simpler and easier to maintain than the code for CLI arguments.
Your arguments about configs breaking would also apply for a wrapper script which is what you propose for a workaround, because config settings and CLI options would both change at the same time.
Ok, the counterpoints are true. Could I get an example of what sort of non-trivial settings one would want to keep in a config file though? I'm still having trouble seeing the usefulness of this.
Well, the first one is that it would work like 99% of applications out there, instead of requiring users to create custom scripting, simple though it may be.
Another benefit of this would be that if you implement classic waterfall configuration (/etc, ~/, ./ - some even check in parent folders up to root) and/or add a --config=
I might have a config file in my mp3 folder and a different one in my flac folder, for instance. Or I might want to specify different drive parameters depending on which dock my laptop is currently in - and not have to remember them. The point of a good config file is to have peace of mind that it will just do the thing I want without having to think about it.
Don't forget that this is an application for (relatively) advanced users, who may have usecases we wouldn't even dream of. If you build it, they will come 😛
Ok, the counterpoints are true. Could I get an example of what sort of non-trivial settings one would want to keep in a config file though? I'm still having trouble seeing the usefulness of this.
- Having a more or less canonical way to configure it is a benefit, as it would be easier to provide assistance and generally make it simpler for people to set up.
- You'd have a configuration files residing in a standard locations, which would make it more uniform across systems, allowing for easier backup and syncing if you're using the same configuration across multiple computers.
- The fact that how you configure it is tied to the application itself means that the same configuration can be reused even if you replace your scripting software or shell.
- As mentioned above, the ability to have central configuration files with the ability to override with local configuration files can be very useful and is a common pattern for configuration in a lot of other applications.
- In general, scripting or aliasing to achieve these things become more tedious and harder to maintain once you have more than one drive. For instance, being able to configure the drive offset per drive would actually be really useful.
So I'd say there are plenty of benefits, and I cannot see any downsides that outweigh the benefits.