Ricardo Wurmus <rek...@elephly.net> writes:
Sergey Trofimov <s...@sarg.org.ru> writes:
- adding it to guix increases maintenance burden: new versions
could
add or remove config options
This is why there should be automated tests. There are too few
of them.
that adds up to the pile of boilerplate to implement a simple
config. If guix mandates it for new packages, it'll raise the bar
for contribution even higher than it already is.
- it bloats guix: imagine if we add configs for every
user-configurable app
That would be nice.
If we started to accept the term bloat we could easily apply it
to
anything in Guix: all that R stuff? Bloat! All that bioinfo
stuff?
Bloat!
imo, R and bioinfo should be in channels.
- such configs are not easily transferrable: if I were to use
the
same app in non-guix env, I'd have to maintain 2 configs
We are generating configuration files from our config languages.
So you
would only need to generate them and copy them for your non-guix
environment.
Sure, that's why I wrote "not easily". My non-guix env is a
corporate Mac laptop. Currently I just clone my dotfiles, symlink
required configs and it's done. I can make changes in both
environments and there is no unnecessary "compiling" step
involved.
Another recent example is `oci-container-configuration` which
defines
a subset of docker-cli startup arguments. The problem is that
`docker
run` command has 96 options and the configuration only uses a
handful,
lacking a way to provide the remaining ones.
All config bindings need to have an escape hatch.
That would be great.
