Closed voidcontext closed 1 month ago
Sorry, what is home-manager?
Sorry, what is home-manager?
Ah, ok, how familiar are you with nix?
Enough to know what nix is, but I don't use it at all so I'm largely unfamiliar with any details
Enough to know what nix is, but I don't use it at all so I'm largely unfamiliar with any details
Ok, so, just like nixpkgs is a collection of modules that can be used to build a linux distro, home-manager is a collection of nix modules to manage users home directory / dotfiles (not just on nixos, but oanywhere where nix is supported, e.g. on macOS).
Got it - so having the $STEEL_HOME set should be fine. I don't know that I've ever really tested using sym linked files for imports. I can poke around and see how steel handles them
It seems, with the current version, the STEEL_HOME
env var is not needed, and symlinking the lib/steel
directory as ~/.config/helix/helix
is sufficient.
So the config can be simplified to
xdg.configFile."helix/helix".source = ${helix-with-steel}/lib/steel;
Which is I think good enough.... Is there anything else that should be sorted in this PR?
I ran across a similar difficulty, and my solution is not substantially different: https://github.com/mattwparas/helix/pull/7 (I didn't notice this PR until I had created my own). The difference:
helix
output under /lib/steel
helix-cogs
as a standalone output and puts them under /cogs/helix
I don't feel strongly about which approach we go with, they both make the generated files available. Do you have any thoughts @voidcontext?
This isn't really related to the content of the PR but you mentioned using: export STEEL_HOME="${helix-with-steel}/lib/steel"
. I find that if I put $STEEL_HOME
in the nix store and then use the steel repl, it will complain about being in a readonly filesystem (it wants to put history files in $STEEL_HOME
). Just an FYI.
put
$STEEL_HOME
in the nix store and then use the steel repl, it will complain about being in a readonly filesystem
same here
@evanrichter, @MatrixManAtYrService As I mentioned in https://github.com/mattwparas/helix/pull/3#issuecomment-2242507368, it is not required anymore to set the STEEL_HOME
env var, creating the symlinks works and probaby it's closer to what we want at the end.
I ran across a similar difficulty, and my solution is not substantially different: #7 (I didn't notice this PR until I had created my own). The difference:
* This PR makes the generated files part of the `helix` output under `/lib/steel` * [Add a flake output for the helix cogs #7](https://github.com/mattwparas/helix/pull/7) creates `helix-cogs` as a standalone output and puts them under `/cogs/helix`
I don't feel strongly about which approach we go with, they both make the generated files available. Do you have any thoughts @voidcontext?
This isn't really related to the content of the PR but you mentioned using:
export STEEL_HOME="${helix-with-steel}/lib/steel"
. I find that if I put$STEEL_HOME
in the nix store and then use the steel repl, it will complain about being in a readonly filesystem (it wants to put history files in$STEEL_HOME
). Just an FYI.
@MatrixManAtYrService I like your version too, tbh, I don't mind what is accepted in the end, as far as it's working with home-manager.
To make it work from home-manager, notice that both
STEEL_HOME
must be set, and the files need to be symlinked into~/.config/helix/helix
. If only one of them is set, there are errors because steel cannot load the modules (different ones in each case).I am not sure but I might be related how realtive paths are considered in case of symlinked modules. I tried reproducing the issue, but unfortunately I wasn't able to do that with a simplified scenario. @mattwparas what do you think?