Closed minrk closed 7 years ago
Is this the case where it works for virtual envs yet not --user
?
Is this the case where it works for virtual envs yet not --user?
Yes, precisely. Because of things like this, I'm not 100% sure it's a good idea to do it this way, however with the increasing use of things like conda to install kernels, I think specs are increasingly going to show up on sys.prefix, so I thought I would take a run at it.
I switched it to check for python
instead of jupyter
. This should get the right answer, as long as which python
returns the Python for which Jupyter is installed. In fact, it should do just as good a job as sys-prefix-promise
, which also relies on which python
returning the right thing, so maybe that option should be dropped.
Would you want to tackle this one again @minrk or should we close this?
Sorry, totally forgot this one. Should be fixed.
CI not passing, I'll dig on this one later.
The CI failure should be fixed by #19
rebased after #19, all green.
Ah, sweet
effectively does
which jupyter
without instantiating any subprocesses, and resolvesrealpath(jupyter)/../..
for the prefix.I also removed the
sort
calls from the tests, which hid a bug where the ordering of system data dirs was not correctTests pass on OS X with conda Python, as well as virtualenvs.
Another option is to check on
python
, rather thanjupyter
. Therealpath
in that case will give the right answer for homebrew Python, which this doesn't (no change from master). The disadvantage is that it will include Python's prefix whether the Jupyter Python package is installed or not, and there isn't a way to identify which Python without reading the shebang line of the Jupyter script, and I wanted to make sure that no files were opened or processes executed.If Jupyter is installed with
--user
, this will add the user prefix, which is not on the Python implementation's path, so will generally turn up no results.