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

Invoke nix on unsupported/unknown subcommands #109

Open
lorenzleutgeb opened this issue Aug 25, 2023 · 6 comments
Open

Invoke nix on unsupported/unknown subcommands #109

lorenzleutgeb opened this issue Aug 25, 2023 · 6 comments
Labels
enhancement New feature or request

Comments

@lorenzleutgeb
Copy link

lorenzleutgeb commented Aug 25, 2023

I did alias nix=nom, and was very pleased with my new nix build experience. Then, I wanted to run nix repl, and was frustrated that nom does not "forward" this command to nix transparently, i.e., it did not invoke nix repl.

As long as you don't support all nix subcommands, please consider to just invoke nix: The command nom foobar should invoke nix foobar.

In the meantime, I'll be using this workaround via Home Manager:

pkgs.writeShellApplication {
  name = "nix-nom";
  text = ''
    set -euo pipefail
    if [ "$1" = "build" ] || [ "$1" = "shell" ] || [ "$1" = "develop" ]
    then
      ${pkgs.nix-output-monitor}/bin/nom "''${@:1}"
    else
      ${osConfig.nix.package}/bin/nix "''${@:1}"
    fi
  '';
}

(and alias nix=nix-nom)

@lorenzleutgeb lorenzleutgeb changed the title Invoke nix on unknown subcommands Invoke nix on unsupported/unknown subcommands Aug 25, 2023
@maralorn
Copy link
Owner

I have pondered this for quite a while and I certainly want a good solution for this. Sadly I see a huge footgun potential here. nom takes nix from the PATH. In your case with the alias you are actually fine, but imagine someone using a symlink nix -> nom, then nom will recusively call itself.

@maralorn
Copy link
Owner

Ah, well. You actually don't set nix -> nom.

@lorenzleutgeb
Copy link
Author

lorenzleutgeb commented Aug 25, 2023

I agree that symlinking nix -> nom is a no-go. Also, removing nix from $PATH is a no-go.

In some cases (nom [build|develop|shell]) nom will exec nix anyway. I am asking that nom also does this for any other subcommand.

Whether someone wants to alias nix=nom is a different matter. I am not suggesting that nom should do aliasing, but I am asking to really support aliasing. For me, when I read "drop in replacement" (like in your README) I expect a plain alias to work. And not just for a few subcommands, but for all of them. See e.g. mislav/hub where you have an alias git=hub situation.

If I ever have a problem with the alias, I just remove it and run nix directly.

@maralorn
Copy link
Owner

Point taken. I had this on my radar anyway and will look into it.

@zeorin
Copy link

zeorin commented Aug 30, 2023

@lorenzleutgeb you can have a look at my code in #108 to create your own aliases. It's not 100% battle-tested but it's a starting point.

@lorenzleutgeb
Copy link
Author

Thanks @zeorin, that's super cool to see, but way too involved for me at the moment.

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

No branches or pull requests

3 participants