Clicking on .py file downloads it instead of opening it. #1051
Comments
|
Hey @gjover , thank you for reaching out. What version of Jupyter Lab are you using? By default you need to use a right click to open However, if you follow the instructions With a click on the text file in JupyterLab in the README.md, you should be able to do what you expect i.e. open Please let us know if that works for you. |
|
Hi, one can see this behavior in this binder: |
|
Hey @gjover , thank you for the link. I have been able to reproduce the documented behavior on Binder (with both your binder and the binder for this repository). Locally I have not yet been able to reproduce. Do you have the same issue locally? If so, could you please share the output of |
|
This issue also happens on binderhub with md files like this. I haven't been able to reproduce it in local, but it was working fine in binder only a few weeks ago.
|
|
When I execute while when I run it on @gjover 's binder I get these versions: I don't have time now for this, but it would be interesting to test whether we can reproduce the issue locally by installing these versions. |
|
Just to say - we have this problem with our 2i2c JupyterHub and it's making a mess of our textbook pages - so if there's anything I can do to help debug - please let me know. |
|
Hi @matthew-brett . Yes sure I can imagine the impact of this... I am not able to reproduce locally (more on this below). If someone else could confirm that the issue does not occur locally we could probably open an issue with https://github.com/jupyterhub/repo2docker. What do you think? Locally I have changed my env to have which mimics most of @gjover 's env on Binder, and still the issue is not present here. |
|
I too cannot reproduce it locally. However, @yuvipanda did reproduce it locally, and I don't think we ever worked out what might differ between our systems. @yuvipanda - can you comment? I reported my full environment before, that does not have the problem locally, but it was:
After that, opening I get the same (correct JupyterText behavior in classic) from the same procedure on an Intel Mac running Homebrew Python 3.9.16, in Firefox, Safari and Chrome. Likewise for a Rasberry Pi running Raspbian Python 3.9.2. |
|
Sorry - also - I think someone else at 2i2c - ?Pris - also succeeded in reproducing locally "a conda/mamba environment", but I know no more details than that. I can reproduce it, serving the notebooks from a recentish Jupyter-Notebook-based container: https://github.com/lisds/lisds-images/tree/2283cf4/lishub-base |
|
@matthew-brett then I would recommend opening an issue at https://github.com/jupyterhub/repo2docker/issues Also do you have the same issue with JupyterLab? For another project I use JupyterLab rather than Notebook and that one seems to continue working as expected, cf. this link (a custom |
|
For me - JupyterLab works as expected - but for my students, using the same hub, they have to right-clck open-as to open as a notebook. I've added the fix you referred to - will ask the students whether that resolves it for them. However, I'd like to use Classic if I can - I'm still getting some bugs with Lab. |
|
Sorry to ask - but for a correct image setup, what configuration should be present for Classic? At the moment, I have: Is there anything else I could try to configure the image correctly? |
Thanks for asking actually! Well it has been a long time I last setup a binder but my expectation is that you only have to install |
|
The explicit contents manager step was a debug hack of last resort. My speculation was that the binder / JupyterHub setup somehow disabled the Jupytext configuration. Is that possible? How would I detect it if so. What would a bug-report to https://github.com/jupyterhub/repo2docker/issues look like? I'm worried that I don't understand the configuration process well enough to say anything more than "Jupytext configuration used to work and now it doesn't" - to which the obvious reply is - not our problem ... |
|
Here are the instructions I used locally to reproduce this.
I can reproduce these as of now, on Mac OS, python 3.10. Here's the full list of installed packages: aiofiles==22.1.0 aiosqlite==0.18.0 anyio==3.6.2 appnope==0.1.3 argon2-cffi==21.3.0 argon2-cffi-bindings==21.2.0 arrow==1.2.3 astroid==2.15.0 asttokens==2.2.1 attrs==22.2.0 autopep8==1.6.0 Babel==2.12.1 backcall==0.2.0 beautifulsoup4==4.12.0 black==23.1.0 bleach==6.0.0 certifi==2022.12.7 cffi==1.15.1 charset-normalizer==3.1.0 click==8.1.3 comm==0.1.2 debugpy==1.6.6 decorator==5.1.1 defusedxml==0.7.1 dill==0.3.6 docstring-to-markdown==0.11 executing==1.2.0 fastjsonschema==2.16.3 flake8==6.0.0 fqdn==1.5.1 idna==3.4 ipykernel==6.22.0 ipython==8.11.0 ipython-genutils==0.2.0 isoduration==20.11.0 isort==5.12.0 jedi==0.18.2 Jinja2==3.1.2 json5==0.9.11 jsonpointer==2.3 jsonschema==4.17.3 jupyter-events==0.6.3 jupyter-ydoc==0.2.3 jupyter_client==8.1.0 jupyter_core==5.3.0 jupyter_server==2.5.0 jupyter_server_fileid==0.8.0 jupyter_server_terminals==0.4.4 jupyter_server_ydoc==0.8.0 jupyterlab==3.6.2 jupyterlab-pygments==0.2.2 jupyterlab_server==2.20.0 jupytext==1.14.5 lazy-object-proxy==1.9.0 markdown-it-py==2.2.0 MarkupSafe==2.1.2 matplotlib-inline==0.1.6 mccabe==0.7.0 mdit-py-plugins==0.3.5 mdurl==0.1.2 mistune==2.0.5 mypy==1.1.1 mypy-extensions==1.0.0 nbclassic==0.5.3 nbclient==0.7.2 nbconvert==7.2.10 nbformat==5.8.0 nbgitpuller==1.1.1 nest-asyncio==1.5.6 notebook==6.5.3 notebook_shim==0.2.2 packaging==23.0 pandocfilters==1.5.0 parso==0.8.3 pathspec==0.11.1 pexpect==4.8.0 pickleshare==0.7.5 platformdirs==3.1.1 pluggy==1.0.0 prometheus-client==0.16.0 prompt-toolkit==3.0.38 psutil==5.9.4 ptyprocess==0.7.0 pure-eval==0.2.2 pycodestyle==2.10.0 pycparser==2.21 pydocstyle==6.2.3 pyflakes==3.0.1 Pygments==2.14.0 pylint==2.17.0 pyls-isort==0.2.2 pylsp-mypy==0.6.6 pylsp-rope==0.1.11 pyrsistent==0.19.3 python-dateutil==2.8.2 python-json-logger==2.0.7 python-lsp-black==1.2.1 python-lsp-jsonrpc==1.0.0 python-lsp-server==1.7.1 pytoolconfig==1.2.5 PyYAML==6.0 pyzmq==25.0.2 requests==2.28.2 rfc3339-validator==0.1.4 rfc3986-validator==0.1.1 rope==1.7.0 Send2Trash==1.8.0 six==1.16.0 sniffio==1.3.0 snowballstemmer==2.2.0 soupsieve==2.4 stack-data==0.6.2 terminado==0.17.1 tinycss2==1.2.1 toml==0.10.2 tomli==2.0.1 tomlkit==0.11.6 tornado==6.2 traitlets==5.9.0 typing_extensions==4.5.0 ujson==5.7.0 uri-template==1.2.0 urllib3==1.26.15 wcwidth==0.2.6 webcolors==1.12 webencodings==0.5.1 websocket-client==1.5.1 whatthepatch==1.0.4 wrapt==1.15.0 y-py==0.5.9 yapf==0.32.0 ypy-websocket==0.8.2 Hope this is helpful. |
|
I can also validate that jupytext is installed, and shows up in |
|
Thank you so much, @yuvipanda ! This is super helpful. I will have a look at this tonight. Naive question: Why are you accessing the url through |
|
Not related to binder, it was just how it was originally reported to us. nbgitpuller just redirects you to the end URL eventually, so it should ideally be irrelevant, other than deciding if it goes through via classic notebook or lab. |
|
Just to confirm the previous clash of our experience - I followed Yuvi's recipe exactly, with the addition, that I moved my I get the correct loading of the notebook with those exact steps. Mac M2, Homebrew Python 3.10.10: |
|
@yuvipanda - I notice you've got quite a few refactoring packages like I have also done |
|
Ah, I forgot my venv setup installs some language server stuff. I made a fully clean venv, and got the same behavior as before. Here's aiofiles==22.1.0 aiosqlite==0.18.0 anyio==3.6.2 appnope==0.1.3 argon2-cffi==21.3.0 argon2-cffi-bindings==21.2.0 arrow==1.2.3 asttokens==2.2.1 attrs==22.2.0 Babel==2.12.1 backcall==0.2.0 beautifulsoup4==4.12.0 bleach==6.0.0 certifi==2022.12.7 cffi==1.15.1 charset-normalizer==3.1.0 comm==0.1.2 debugpy==1.6.6 decorator==5.1.1 defusedxml==0.7.1 executing==1.2.0 fastjsonschema==2.16.3 fqdn==1.5.1 idna==3.4 ipykernel==6.22.0 ipython==8.11.0 ipython-genutils==0.2.0 isoduration==20.11.0 jedi==0.18.2 Jinja2==3.1.2 json5==0.9.11 jsonpointer==2.3 jsonschema==4.17.3 jupyter-events==0.6.3 jupyter-ydoc==0.2.3 jupyter_client==8.1.0 jupyter_core==5.3.0 jupyter_server==2.5.0 jupyter_server_fileid==0.8.0 jupyter_server_terminals==0.4.4 jupyter_server_ydoc==0.8.0 jupyterlab==3.6.2 jupyterlab-pygments==0.2.2 jupyterlab_server==2.20.0 jupytext==1.14.5 markdown-it-py==2.2.0 MarkupSafe==2.1.2 matplotlib-inline==0.1.6 mdit-py-plugins==0.3.5 mdurl==0.1.2 mistune==2.0.5 nbclassic==0.5.3 nbclient==0.7.2 nbconvert==7.2.10 nbformat==5.8.0 nbgitpuller==1.1.1 nest-asyncio==1.5.6 notebook==6.5.3 notebook_shim==0.2.2 packaging==23.0 pandocfilters==1.5.0 parso==0.8.3 pexpect==4.8.0 pickleshare==0.7.5 platformdirs==3.1.1 prometheus-client==0.16.0 prompt-toolkit==3.0.38 psutil==5.9.4 ptyprocess==0.7.0 pure-eval==0.2.2 pycparser==2.21 Pygments==2.14.0 pyrsistent==0.19.3 python-dateutil==2.8.2 python-json-logger==2.0.7 PyYAML==6.0 pyzmq==25.0.2 requests==2.28.2 rfc3339-validator==0.1.4 rfc3986-validator==0.1.1 Send2Trash==1.8.0 six==1.16.0 sniffio==1.3.0 soupsieve==2.4 stack-data==0.6.2 terminado==0.17.1 tinycss2==1.2.1 toml==0.10.2 tornado==6.2 traitlets==5.9.0 uri-template==1.2.0 urllib3==1.26.15 wcwidth==0.2.6 webcolors==1.12 webencodings==0.5.1 websocket-client==1.5.1 y-py==0.5.9 ypy-websocket==0.8.2 |
|
I primarily use Firefox, perhaps this is browser related? |
|
I said this in the previous thread, but I tried on Safari and Chrome as well, with the same result (correct Jupytext behavior). I usually use Firefox too. Did you move your |
|
@yuvipanda I confirm that I can reproduce this locally. I have followed the following steps: Now what puzzles me is that not all the
Below are the logs when I click on It has been a long time since I last looked at these kind of logs but obviously the issue is related to the 'GET' evens. If I redo the same with followed later on by when the second file is opened as a notebook. This seems to be consistent with the fact that My expectation is that Jupytext tells Jupyter that both files are notebooks, and at least from the icons this seems to be the case. I am not sure what part of Jupyter decides how to build the GET query. @yuvipanda any idea? |
@mwouts, I noticed that before going to the URL with the My best guess is that this redirect is set by nbclassic in https://github.com/jupyter/nbclassic/blob/f237e24acf1f6a7f08c0593a75a41f5e618b2832/nbclassic/notebookapp.py#L256-L265. |
|
Interesting! Thank you @GeorgianaElena for the pointers.
Yes - I think this is consistent with the notebook icon on the
Do we know where the 301 might come from? I see it means moved permanently... Isn't that surprising? Any idea which part of the code generates that HTTP status code? |
|
To be more explicit, I am looking for a quick workaround for this in the form of 'downgrade package xxx to version yyy' - the question is which package 😄 ... and then, we will take the time to provide a proper fix. |
I believe it might be coming from the tornando's RedirectHandler set by nbclassic here.
I'm not sure about this. Are there any Jupytext tests against a |
|
Hi @GeorgianaElena , well yes this is super helpful!
No you're right, I have never tested this
Agreed! By the way, in the empty virtual env above where we just do |
|
This is one of the strangest bug I have ever seen. In the virtual env described above, then
Also, I usually use Firefox, but if I open the notebook server in Chromium then it works fine. I have the feeling that I know too little JS to address this issue. On the Python side I have tried to suppress the tornado redirect mentioned by @GeorgianaElena, that had no effect. I have also search for 301 in my env, and could not find anything obvious. I have suspected that the async transition of @yuvipanda , @GeorgianaElena , @fcollonval , do you thing we could get help from the Jupyter Core team on this? Again the description of the issue is the following:
I find this issue strange because:
|
|
I see that I can clear the 301 redirect cache in Firefox with Ctrl+Shit+Delete. This is probably what I missed when doing experiments on the Python side. |
|
After clearing the cache I see that, to reproduce, I need to The logs say: and despite the |
|
Indeed @GeorgianaElena you were right, Jupytext and NBclassic never worked together. A temporary workaround for this is (don't forget to clear the browser cache) I am not sure how this workaround would translate to Binder. A fix for (the redirect does not seem to be required to open text files in edit mode neither). I will now open a PR on |
|
A temporary workaround for Binder is to add this to the |
|
Thanks! That workaround works for me, setting up an image for a current JupyterHub (in fact on 2i2c). |
|
The definitive workaround is to require I plan to delete my fork of |
|
FYI I have just deleted my fork of |
Scenario:
Issue
Expected behaviour
Environment
I have test it in Chrome and Firefox
versions:
rise 5.7.1
jupyter 1.0.0
jupyter_contrib_nbextensions 0.7.0
jupytext 1.14.4
The text was updated successfully, but these errors were encountered: