3 ms·

I don't follow, is it easier to automate a ton of args than to automate a config file? Or better yet, put the config file in the bundle you're distributing, sin

I don't follow, is it easier to automate a ton of args than to automate a config file? Or better yet, put the config file in the bundle you're distributing, since it probably benefits from the same change management flow?

hamandcheese 4y ago
> I don't follow, is it easier to automate a ton of args than to automate a config file? Yes? With just flags, the only artifact that you depend on is the program. With a config file, now there is a separate artifact to maintain for every distinct configuration, which could be a lot. I'm not saying its not solvable, but it does strike me as more complicated.
- closeparen 4y ago
  I guess if you're distributing standalone binaries, that makes sense. The distribution systems I have seen are all tarballs, packages, or container images, where one more file is no problem. There must be some kind of config system where the flags are being driven from though, unless someone is manually typing them out each time.
- marcthe12 4y ago
  They could done what bwrap does where there is a special CMD flag that tell program to read the flags from FD. So in flatpak which generally has to give a few kbs of flag to bwrap just pass this via FD. Now whether this works on all supported platform is an another question in it self
makeitdouble 4y ago
On automation, if you are building the config dynamically from external or computed parameters, in the case of a config file you'll need to: - open some descriptor on the system - write the file content - execute the command - get rid of the file Of course you'll also need to deal with the constraints/failure of any of these steps (write the file in a location the program can access, take care it still exists or is not overwritten when you run the command, so have pseudo random names and/or lock the file, etc.) In comparison, passing it all as args is one single step.
- closeparen 4y ago
  Fair. There are all those "configuration management" frameworks that make templating out config files from data a fairly solved problem, but if you're launching programs from other programs that you also wrote, I guess it's less code to have an arbitrarily long arguments list vs. also dealing with files.

hamandcheese 4y ago

> I don't follow, is it easier to automate a ton of args than to automate a config file? Yes? With just flags, the only artifact that you depend on is the program. With a config file, now there is a separate artifact to maintain for every distinct configuration, which could be a lot. I'm not saying its not solvable, but it does strike me as more complicated.

closeparen 4y ago
I guess if you're distributing standalone binaries, that makes sense. The distribution systems I have seen are all tarballs, packages, or container images, where one more file is no problem. There must be some kind of config system where the flags are being driven from though, unless someone is manually typing them out each time.
marcthe12 4y ago
They could done what bwrap does where there is a special CMD flag that tell program to read the flags from FD. So in flatpak which generally has to give a few kbs of flag to bwrap just pass this via FD. Now whether this works on all supported platform is an another question in it self

makeitdouble 4y ago

On automation, if you are building the config dynamically from external or computed parameters, in the case of a config file you'll need to: - open some descriptor on the system - write the file content - execute the command - get rid of the file Of course you'll also need to deal with the constraints/failure of any of these steps (write the file in a location the program can access, take care it still exists or is not overwritten when you run the command, so have pseudo random names and/or lock the file, etc.) In comparison, passing it all as args is one single step.

closeparen 4y ago
Fair. There are all those "configuration management" frameworks that make templating out config files from data a fairly solved problem, but if you're launching programs from other programs that you also wrote, I guess it's less code to have an arbitrarily long arguments list vs. also dealing with files.