RFC: notion which

[thoov]

which now returns the path to a given shim. Add a new command notion which that will return the path to the underlining executable instead of the shim

Rendered

[charlespierce]

• Should notion which work exactly like which or should it only work for executables that notion "owns"?

I think I would want notion which to work for anything, so that users aren't having to constantly switch between which and notion which, based on the result of running one or the other. If we can make notion which cover everything, then it's easy to explain to users that they can use notion which for any executable.

• Should notion shim which instead of adding a new command?

My only concern with shimming which is that one of the goals of Notion is to be cross-platform, which would mean we would need to shim the windows where.exe as well, and then we're potentially messing with developers' environments more than we want to.

That said, it would be nice to have an alias for the command notion where, so if there is a Windows dev used to using where they can adjust just as easily as a unix dev using which.

• Should notion which support all of the options that which does?

I think for an initial implementation, it would be cleanest to just support the basic use-case of printing out the paths without any of the options. We can later take a look at potential options, but for cross-platform support, we probably want to dive deep on what options are available to both which and where. That shouldn't be a blocker for the basic functionality IMO.

[thoov]

@charlespierce

I think I would want notion which to work for anything, so that users aren't having to constantly switch between which and notion which, based on the result of > running one or the other. If we can make notion which cover everything, then it's > easy to explain to users that they can use notion which for any executable.

I agree

I think for an initial implementation, it would be cleanest to just support the > basic use-case of printing out the paths without any of the options. We can later take a look at potential options, but for cross-platform support, we probably want to dive deep on what options are available to both which and where. That shouldn't be a blocker for the basic functionality IMO.

I agree

[dherman]

The idea of Notion shimming which has always made me pretty uncomfortable. @charlespierce's point about cross-platform is one reason, but also just because it feels like it's violating the intended behavior of which, whose purpose is to tell you the result of the PATH resolution algorithm.

Should notion which work exactly like which or should it only work for executables that notion "owns"?

That sounds like it's probably the most useful behavior for common use cases. It might also make sense to have a lower-level ("porcelain") command, maybe with a lower-level name like shim-path that only tells you where a shim will redirect if it's a shim and otherwise fails. IOW, notion which foo would be equivalent to notion shim-path foo || which foo.

That said, it would be nice to have an alias for the command notion where, so if there is a Windows dev used to using where they can adjust just as easily as a unix dev using which.

The syntax and behavior of which and where are slightly different, so they probably shouldn't be aliases but each should behave like its respective precedent.

I think for an initial implementation, it would be cleanest to just support the > basic use-case of printing out the paths without any of the options.

Agreed. We can probably punt shim-path and where to separate RFCs as well.

[rwjblue]

I believe this has landed already (https://github.com/volta-cli/volta/pull/293 and https://github.com/volta-cli/volta/pull/419, maybe more).

Seems like this should be merged?