handling commands that run other commands in a different path-space (different system, chroot, vm, etc.)

[abathur]

I think the main questions that help tease out whether these are on resholve's turf are:

1. whether a given case has a safety/accuracy problem that's detectable from resholve's perspective
2. whether there's a meaningful/productive way for resholve to intervene to improve the situation

[abathur]

One (potentially worst-case) example is an ssh invocation that would run commands on another system.

• resholve could in theory recognize an ssh invocation that would run remote commands (and what those commands are), but there's no perfect way to durably resolve them to stable paths on a remote system--especially not within the constraints of a Nix build.
• I suspect the most-principled approach possible would require access to the remote system and some big assumptions: that the same alias/ip/hostname will always lead to the same device, and that the paths available on it won't change after resolve time.
• it's probably worth weighing whether less-principled approaches are worth their weight?
  • resholve might be able to detect each distinct alias/user+(host|ip) and make the user supply a corresponding list of executables on the system, resolve from them, and leave consistency up to the user. Maybe resholve could emit a command or script they could use to collect all of the executables on the target PATH into a file that resholve can use at resolution time.
  • resholve could detect these and warn the user until they supply a directive (basically, forcing them to acknowledge that resholve has informed them that the remote system needs git on PATH, or whatever). I'm not sure if it would make sense to bother detecting precise hosts and such in this case--just make the user look at each invocation.
  • resholve could allow these through without any special argument, but also emit a warning that they exist
  • resholve could try to generate and inject code to test for and alert about these at run time (but this smells like a lot of work just to leave the user with a run-time-bomb on their hands...)

[abathur]

Another example is nixos-enter (brought up in #81 (comment)) which will run the commands in a chroot (potentially with or without a shell) on the same system. Despite being nixos-native, I suspect this case is actually very similar to the ssh case? If I'm understanding it, the chroot would contain the system packages (which could also change between invocations)?

• In the best case, information available within the Nix build would be sufficient to confirm whether the paths would exist in the chroot (and it would be possible to stably map paths into the chroot form if necessary.)
  • I suspect this would entail the package that invokes nixos-enter having an explicit reference to the system profile and some way for resholve's Nix API to feed resholve all of the packages in that system profile? We wouldn't want these to be the inputs resholve uses for the whole script, so resholve would probably need some way to specify inputs specific to a specific command or invocation (i.e., we'd need to be able to specify a separate PATH that is just used for all instances of nixos-enter, or for a specific invocation.
• Might have some corner-cutting options if the packaging case is very constrained. Say, we have a small number of invocations for nixpkgs itself and we know they only run things that will always be on a nixos PATH?
  • Back off entirely if the executables will always be present and the PATH set right?
  • Focus effort on mapping the profile part of the path?