New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pythonPackages.jupyter_core: fix search path #83619
pythonPackages.jupyter_core: fix search path #83619
Conversation
should this be upstreamed? |
What type of environment is that? Please show an example how it does not function. |
I'm not sure if it should be upstreamed since I'm not sure if this just because of a unique use case I had. I had this when attempting to launch a Jupyter server through the vscode python extension (direnv and lorri mix to get the python linked into the folder)
and Another solution would be patching the sysconfig of new python environments, but I'm not sure if it's really needed. |
- scripts = [sys.argv[0]] | ||
+ scripts = [sys.argv[0],sys.executable] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit confused here; perhaps you can fill in something I'm missing.
In a comment, you say that when you run into the issue this is meant to fix:
sys.argv[0]
is pointing to the raw python interpreter instead of the wrapper.
But sys.executable
is itself meant to be the path to the Python interpreter. (That's its documented meaning upstream, at least.)
What path is sys.executable
pointing to in the situation where you're seeing the issue, and how does it relate to the path pointed to by sys.argv[0]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not too sure on how the those are actually evaluated, but sys.argv[0]
doesn't point to sys.executable
since I had to make this in the first place.
The actual python script in the python-env
is a wrapper that calls the python interpreter, so that's probably why sys.argv[0]
evaluates to the interpreter while sys.executable
refers to the script that started it.
I'll be able to get some output to illustrate this tomorrow.
I have a Python environment installed system-wide on NixOS: $ cat $(readlink -f $(which jupyter))
#! /nix/store/z4ajipns0l1s8b2lrgpy6nng4cys7h99-bash-4.4-p23/bin/bash -e
export NIX_PYTHONEXECUTABLE='/nix/store/bba1as20vdsh8clzjiyybk4n5ymph5z6-python3-3.7.6-env/bin/python3.7'
export NIX_PYTHONPATH='/nix/store/bba1as20vdsh8clzjiyybk4n5ymph5z6-python3-3.7.6-env/lib/python3.7/site-packages'
export PYTHONNOUSERSITE='true'
exec "/nix/store/96f3b85v9bd31n3x4pv9xi8j9accajj2-python3.7-jupyter_core-4.6.1/bin/jupyter" "$@"
It functions in the following cases:
In a composed environment one should expect all executables can find each other, so we should add |
4d0f9ec
to
a1fb399
Compare
a1fb399
to
6ae6ec5
Compare
I marked this as stale due to inactivity. → More info |
@eadwu ping |
Motivation for this change
Not sure if this is expected but if one does
python.withPackages (ps: [ ps.jupyter ])
, thejupyter-*
commands aren't found in environments wherePATH
isn't propagated from the shell environment.Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)