Package executables

[mikrostew]

Many Node packages contain one or more executable files that they would like to install into the PATH. Notion should make these executables available to the user:

• locally, on a per-project basis (project tools)
• globally, installed as if they are static binaries (user tools)

Rendered

[rwjblue]

Overall this is a really nice write up, and helps rationalize the mental model around these tools.

I’m still struggling a bit on the shims section though. It seems like the shims are only used to defer to project local executables, right? Since the shims are globally installed (AFAICT there is only one set of them in the ~/.notion/.bin directory), the $PATH (along with tools like which some-name) still expose the executable name in areas where it is actually not supported.

[dherman]

@rwjblue A key point is that the shim's default behavior, when there's no installed tool, is to delegate to whatever binary has that name next in $PATH. So it acts basically as if the shim isn't there at all.

Now, as you say, this does show through when you do things like which some-name. We also need a notion which command to find out the actual command that the shim will run, so you can see past the shims.

For the most part, when you use Notion you really don't need to think about shims. But it does show through with which. That does have the downside of having to learn to use notion which if you're trying to get past the shims. The primary alternatives would be (1) cd hooks or (2) more manual context switching. We've chosen shims over cd hooks because they're not necessarily available on all platforms, it's harder to achieve portability, and many people distrust them because of historical bugginess. And manual context switching requires more mental overhead everywhere, and is error-prone.

[rwjblue]

Now, as you say, this does show through when you do things like which some-name. We also need a notion which command to find out the actual command that the shim will run, so you can see past the shims.

Hehe, well, we could allow folks to shim which itself (probably should be an opt-in?) to return the 'real' path to things by default.

Specifically, we could add a which to the $PATH which is notion which such that the shims themselves aren't even visible. I think the only real question there is if we truly think that which is the only place where our facade "bleeds through". If it is, then this might be viable (if it isn't then its a giant game of "whack-a-mole" that we shouldn't even be playing).

[dherman]

@rwjblue We'd definitely discussed that, but it makes me nervous. It feels like it's overriding a core behavior of the shell that you can't easily get back. And it feels like it's asking for bugs, for example if a shell script saves SOME_TOOL=$(which some-tool) in one directory and then changes directories and calls $($SOME_TOOL), it'll basically circumvent the behavior of Notion, even though the user had Notion installed.

I think another way to think of this is that which is a primitive of the shell, and Notion is operating at a higher layer of abstraction than which. That's a bit hand-wavy and philosophical, but I suspect in practice it may work out ok. Usage experience will give us a sense.

[rwjblue]

Right, that makes sense. I agree that it definitely is quite "magical", and perhaps just being up front with what is going on is better. Either way it is certainly a better starting point.

[dherman]

It occurs to me that I kind of bigfooted this whole RFC with the reproducibility RFC. Or at least, they both have some overlap.

And at the same time, as I commented on that one, I want to remove all the git stuff from it, which is a relatively significant portion of it.

Maybe the right thing to do is reject both RFCs and consolidate them into one new one.

[mikrostew]

@dherman I agree with that. There is a lot of overlap between the two, and not a clear separation between them. They should be consolidated into a new RFC.

[dherman]

Closing since this is superseded by #27.