feat(wrapperModules.gh): init

[rachitvrma]

Wrap github-cli gh using nix-wrapper-modules.

[BirdeeHub]

Since we are already doing some complicated thing here to build the directory, we can make this do placeholders without much extra effort, if you want?

If you set config.drv.nativeBuildInputs = [ pkgs.remarshal_0_17 ];

You can then configContent = builtins.toJSON config.settings;

and json2yaml $configContentPath "${placeholder config.outputName}/gh-config/config.yml" instead of this copy command.

Which is how they do it in nixpkgs

https://github.com/NixOS/nixpkgs/blob/87e875c8ea73c14dd96a883e37c691ab01c9da9e/pkgs/pkgs-lib/formats.nix#L165-L172

---

Alternatively, if you don't want all that, we should be able to simplify this line to

cp "$configYml" "${placeholder config.outputName}/gh-config/config.yml"

and then remove the passAsFile, which is not necessary in this case. configYml in this case as it is currently written contains a path. A single path is very very unlikely to ever exceed the max length for a variable. So if we are going to continue using .generate, you don't need passAsFile there either.

[BirdeeHub]

So, I found a problem with this approach.

It tries to write to its config directory, which is now in the store.

Any chance we can do this with gh config set instead?

[rachitvrma]

Uh, yeah, I wanted to tell you about this problem. A similar one arises where the file hosts.yml has to be written as well, and then it encounters a read-only filesystem. I wonder how home-manager handles it...

Also there's this issue on home-manager. Seems that config.yml is not much of a problem, it's hosts.yml?

[BirdeeHub]

home manager handles it by putting these files in system locations, such that hosts.yml is writable despite config.yml not being writable.

Because they have an activation script.

And gh config set would require running gh several times probably, we can't combine it all into 1 command... (unless they allow that somehow?)

We could set the variable to somewhere outside the store and do runShell and copy it there from the store at runtime before it runs if it isnt maybe? Make sure to make that path configurable and save any files that are there with some extension, also configurable? Its annoying though.

If we did that, you should make the thing you call via runShell also available in the drv to run separately, and some way to choose if it is to ran at runtime automatically or not.

---

It also looks like they list ALL settings as environment variables.

Maybe we just list them all out as explicit options? I somewhat did that for the tmux stuff. But then you, or somebody at least, would have to add more when they add more (if they do).

However, it looks like that is a standardized mapping

There is a GH_UPPERCASED version of each setting

https://cli.github.com/manual/gh_help_environment

https://cli.github.com/manual/gh_config

You should investigate to see if that is an actual thing and they automatically map that intentionally, or just a convention they follow.

---

Im out of ideas for now though