Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to pass arguments to a shell file #8

Open
Unisay opened this issue Sep 7, 2021 · 4 comments
Open

Ability to pass arguments to a shell file #8

Unisay opened this issue Sep 7, 2021 · 4 comments

Comments

@Unisay
Copy link

Unisay commented Sep 7, 2021

I use "stock" nix support in direnv like this:

use nix --arg buildAll false

(which is equivalent to nix-shell --arg buildAll false)

it looks like its not possible to pass ARGs to use_nix_gcrooted

use_nix_gcrooted --arg buildAll false
direnv: too many positional arguments

It would be really helpful if this is supported, thanks!

@shajra
Copy link
Owner

shajra commented Sep 8, 2021

Hi!

I wish this were easier. Here's a copy/paste of the call that does all the magic.

    IN_NIX_SHELL=1 \
        nix-build \
        --show-trace \
        --verbose --verbose \
        --no-out-link \
        --arg src "$shell_file" \
        --expr "((import ${buildSource} {}).build.lorri-eval-$auto_watch_eval)"

This is where I just delegate to Lorri. As you can see, I'm passing the user's Nix file to a build of a Lorri Nix expression. So at this point either:

  • I can see if I can get changes into Lorri
  • See if I can patch Lorri as part of Lorelei
  • Maybe consider if Lorelei and Lorri should combine forces? I feel there's merit to having a daemonless option for Lorri.

Maybe @Profpatsch has thoughts there? Lorelei is mostly a single file shell script, cooked up by Nix. Because it's cooked up by Nix, it just makes calling out to Lorri easy. But Lorri is really doing all the work.

So I think your request is reasonable. I'm hoping the workarounds Nix gives us are workable. You can have a separate file, just
for Lorelei/Direnv. And that way, your normal shell.nix script can be fully parameterized, and your shell.direnv.nix script can be hard-coded with the arguments you are otherwise asking to put in .envrc in the call to use_nix_gcrooted. So I think that solves the problem, but with the worsened ergonomics of yet-another-file you never really wanted.

I'll see if I can stare at Lorri code later to see if it's easier than I think it is at this point.

@Unisay
Copy link
Author

Unisay commented Sep 8, 2021

Thanks @shajra for a detailed explanation! Fun fact: I evaluated Lorri first, lacked that feature and decided to give a try to Lorelei hoping that it can pass arguments and not realizing it uses Lorri under the hood for this :)

The solution with multiple files that you described was on my mind too (as a backup plan in case if passing args directly doesn't work :) At this point I am leaning towards using it as a workaround.

Thanks for the evaluation!

@shajra
Copy link
Owner

shajra commented Sep 8, 2021

@Unisay that's good that the workaround might hold you over. I really think the Lorri way of getting references to GC root is the right (or at least the best) algorithm I've seen. Other approaches have problems with FFI. So I really recommend people use either Lorri or Lorelei for Direnv/Nix integration.

In other news, I did look at Lorri code to remind myself how things connect. And here's a relevant line of code: https://github.com/nix-community/lorri/blob/canon/src/logged-evaluation.nix#L41-L42.

This is the point where you'd like your arguments passed in. So... the amount of patching it would take to get this to thread through is not so much. I do have to build a Nix attr set from Bash CLI arguments, though. But that's on par with the kind of complexity that makes up Lorelei as it stands.

Though... I shouldn't dismiss too quickly the trickiness of delimiting strings.

@shajra
Copy link
Owner

shajra commented Sep 8, 2021

Yeah, quoting with Nix is a wild beast: NixOS/nixpkgs#86021

Everything in Nix has this potential to feel like a hack. Some hacks just have more limitations than others. Maybe normal double quotes are counter-intutively the easier ones to use internally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants