So far, we've been framing -p as "this is the package the binary comes from".
As of d9175e8d03e0fc04e05c1bb72cab0e64c9427412, though, this understanding became something more like "this is a package that should be put in the current environment so that <command> or its sub-processes might find it".
What that means is we can totally have multiple -p options now for folks who want to set up a command that sets up a few tools at a time. One example of this might be:
$ npx -p node-bin@6 -p npm@4 npm --versions
This change has also created another problem that needs to be solved: the "hidden" _npx directory where non-installed binaries end up can now cause hidden, unintended conflicts. That means that we'll have to remove the directory between npx runs altogether. That, or we'll have to put each binary in its own prefix, so we can update them (#11) more efficiently, instead of doing a full install every time.
So far, we've been framing
-pas "this is the package the binary comes from".As of d9175e8d03e0fc04e05c1bb72cab0e64c9427412, though, this understanding became something more like "this is a package that should be put in the current environment so that
<command>or its sub-processes might find it".What that means is we can totally have multiple
-poptions now for folks who want to set up a command that sets up a few tools at a time. One example of this might be:This change has also created another problem that needs to be solved: the "hidden"
_npxdirectory where non-installed binaries end up can now cause hidden, unintended conflicts. That means that we'll have to remove the directory betweennpxruns altogether. That, or we'll have to put each binary in its own prefix, so we can update them (#11) more efficiently, instead of doing a full install every time.