Re: Are declarative app configs worth it?
Ricardo Wurmus writes: Sergey Trofimov 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.
Are declarative app configs worth it?
Hi guix, I want to start a discussion around how to manage user app config files. Copying my message from https://issues.guix.gnu.org/68010, where home-zathura-configuration with 76 fields is proposed. I have mixed feelings about pulling 3rd-party software configurations in guix: - adding it to guix increases maintenance burden: new versions could add or remove config options - it requires documentation/translation, another hidden cost - it bloats guix: imagine if we add configs for every user-configurable app - 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 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. I think guix should not embed config generators for user software. The only need I see for such generators is when there are options which should be the same among multiple applications (e.g. color schemes or shared directories). For such usecase guix should provide better text manipulation tools which home owners could use to parameterise configs. Best regards, Sergey Trofimov
Re: 09/09: lint: Append "/info/refs" to git-reference-url.
Maxim Cournoyer writes:
Hello,
guix-comm...@gnu.org writes:
lint: Append "/info/refs" to git-reference-url.
After this fix, I'm now seeing warnings from Github, e.g.:
gnu/packages/rails.scm:675:2: ruby-activejob@7.0.4.3: scheduled
Software Heritage archival
gnu/packages/rails.scm:282:2: ruby-activemodel@7.0.4.3: URI
https://github.com/rails/rails/info/refs not reachable: 403
("Forbidden")
It seems that the `service=git-upload-pack` is important as it
switches the protocol to "smart-http".
--8<---cut here---start->8---
~/devel/ext λ curl
'https://github.com/sarg/dotfiles/info/refs?service=git-upload-pack'
001e# service=git-upload-pack
Warning: Binary output can mess up your terminal. Use "--output -"
to tell
Warning: curl to output it to your terminal anyway, or consider
"--output
Warning: " to save to a file.
~/devel/ext λ curl 'https://github.com/sarg/dotfiles/info/refs'
Please upgrade your git client.
GitHub.com no longer supports git over dumb-http:
https://github.com/blog/809-git-dumb-http-transport-to-be-turned-off-in-90-days
--8<---cut here---end--->8---
Maybe the linter should just use `git ls-remote` instead of
guessing the url?
--8<---cut here---start->8---
~/devel/ext λ git ls-remote https://github.com/sarg/dotfiles
7707f77e8d9c11b5435c5901eca45be1a72d2054HEAD
7707f77e8d9c11b5435c5901eca45be1a72d2054refs/heads/master
--8<---cut here---end--->8---
