Skip to content
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

Conflict with rye python shims #850

Closed
bluss opened this issue Jul 30, 2024 · 7 comments
Closed

Conflict with rye python shims #850

bluss opened this issue Jul 30, 2024 · 7 comments
Labels

Comments

@bluss
Copy link

bluss commented Jul 30, 2024

Description

In some Rye-using setups:

  • Starting jlab succeeds. Opening notebooks inside the jlab interface works, after selecting appropriate jupyterlab venv
  • Starting jlab notebookfile.ipynb fails to start. Dragging notebook to jlab window fails to open it the same way
    The error there is "Jupyter server process terminated before the initialization completed"

Reproduce

  1. Install Rye
  2. ~/.rye/shims/python is now the first python on $PATH
  3. Install jupyterlab-desktop
  4. Install jupyterlab as python -m pip --user (~/.rye.shims/python user site environment) (Python 3.10)
  5. Install jupyterlab separately in a more appropriate virtual environment "V" (Python 3.12)
  6. Open jlab. Select that you use virtual environment "V" in the drop down in the top of the window
  7. Now try to open a notebook file using jlab notebookfile.ipynb

Expected behavior

jlab notebookfile.ipynb should maybe use the same selected virtual environment "V" that the user interface otherwise defaulted to.

jlab should not try to launch ~/.rye/bin/python as if it is a virtual environment, because it's not (it's a shim for a system interpreter).

Context

The following appeared in the debug log, and this obviously fails, because that activate script does not exist:

source "/home/ulrik/.rye/bin/activate"

This is quite suspicious - the "system python path" is "$HOME/.rye/bin/python" and jlab is treating that as if it's a .venv (it's not, that shim will reexecute to /usr/bin/python which is python 3.10)

  • Operating System and version: Ubuntu 22.04
  • JupyterLab-Desktop version: 4.2.1-1
  • Installer: .deb
  • platform: linux (x86_64)
Troubleshoot Output
Paste the output from running `jupyter troubleshoot` from the terminal inside of JupyterLab Desktop here.
You may want to sanitize the paths in the output.
Browser Output (required for interface issues after loading)
Paste the output from the DevTools JavaScript console here, if applicable.
Logs (required for issues with loading, server and startup)
Paste the logs from the `main.log` file here (optionally also from `renderer.log`).

Suggested Workaround

Make sure jupyter is not installed in any system interpreter's user site.

Thanks for the nice work on jupyterlab desktop :)

@JasonWeill
Copy link

This looks like the same error message as in #847, although that issue mentions Windows 10 and doesn't mention Rye.

@JasonWeill
Copy link

Out of curiosity, if you're not using Rye, do you see the same "Jupyter server process terminated before the initialization completed" error? If so, this might effectively be a duplicate of #847.

@bluss
Copy link
Author

bluss commented Jul 30, 2024

bild
It's a very generic error message, I'm not surprised if separate problems can lead to the same place.

If I don't use rye I don't have the problem.

@bluss
Copy link
Author

bluss commented Jul 30, 2024

When this happens I can grab the launch script from the log - something like /tmp/jlab_desktopfiS6Bd/launch.sh - and that script starts jupyterlab correctly when I run it separately. So that's mysterious.

From the log:

[2024-07-30 19:17:39.523] [error] Failed to start server Error: Jupyter Server process terminated before the initialization completed
    at ChildProcess.<anonymous> (/opt/JupyterLab/resources/app.asar/build/out/main/server.js:295:28)
    at ChildProcess.emit (node:events:514:28)
    at Process.onexit (node:internal/child_process:291:12)

@bluss
Copy link
Author

bluss commented Jul 30, 2024

I can see now later that the source "/home/ulrik/.rye/bin/activate" is a red herring. (or maybe not?) but even cases that work print commands like source "/usr/bin/activate" - another path that doesn't usually exist. (Which by the way is a correctness or even safety hazard - one can't just rely on that path not existing. It could be something that wrecks the execution.)

@JasonWeill
Copy link

It looks like there's an issue concerning using Rye shims with JupyterLab, among other projects: astral-sh/rye#1093

I'll keep this issue open to track it from Jupyter's perspective, but there might need to be some work done in Rye to prevent errors like this one.

@bluss
Copy link
Author

bluss commented Sep 7, 2024

I'll abandon this bug as uv has taken over all rye's features, and I do not use rye anymore.

@bluss bluss closed this as completed Sep 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants