Closed JoranDox closed 2 years ago
Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.
You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:
from gitter:
Nicholas Bollweg @bollwyvl Oct 13 15:01 seems possible you're hitting some virtual env/path stuff: the environment variables (like PATH) you get inside a ! magic is often not the same as the process running the kernel
JoranDox @JoranDox 10:07 @bollwyvl I too suspect something like that, I do know we're not using virtual envs but we are using custom home directories (and possibly other similar stuff) and there's a good chance that's breaking things. Is there a way to reliably find out what is used by the process that is actually loading the workspace on jupyter boot? And I suppose running env in the terminal gives mostly the same env as I'd get from using a ! magic? Though I've noticed the output from --debug in the export being slightly different (though the result is unchanged, still wrong)
test
?File
menu → Save current workspace as
?jupyter lab export
and just loading them using the urls)
c. the json in the file looks a lot more complete vs the one I got using jupyter lab export
, this looks like the "correct" oneThanks a lot @krassowski , that's a useful workaround already if nothing else, and a big step towards solving this I think!
Maybe this test
workspace does not get saved properly so it cannot be exported? jupyter lab workspaces list
would really help here, but it is still WIP: https://github.com/jupyterlab/jupyterlab/pull/10923
It seems to also be related to the dask extension itself: I just noticed that after a fresh start of my jupyterlab it wasn't able to load the "saved as" workspace file entirely (just as loading the workspace on starting up), but once I started a dask cluster it worked again.
So that said, my initial question is still valid (jupyter lab export doesn't seem to work) but the dask mystery is unrelated and probably an issue with the dask extension itself.
Description
This screenshot should show most of my issue:
Other things I've noticed that may be relevant:
I've tried looking for similar issues but I either have no idea what keywords to use (except workspace) or I'm the first one to encounter this.
I'm mostly looking for help to know where to start to debug this, as I looked in the output from the
jupyter lab workspaces export test --debug
command and I didn't see anything related to workspaces anywhere in the paths mentioned, and this might also be the actual issue. Where does jlab3 look for its workspaces, and did this change compared to jlab2?Reproduce
!jupyter lab workspaces export test --debug
Expected behavior
output should match the workspace
Context
Troubleshoot Output
Command Line Output
Browser Output