Mybinder JupyterLab link to a repo subfolder works, but not to a specific notebook in that folder

Hi, I am trying to create a JupyterLab link to a specific notebook in a repo subfolder. When I link to a subfolder using JupyterLab it works and shows all the files in JupyterLab, but supposedly I should be able to do this for a specific notebook as well. When I try, it previews that notebook as it launches the binder, but brings up the root folder of my repo.

This is the link I am trying to do to a specific notebook, but goes to my root folder:

This is a link to a subfolder that works fine:

I am probably missing something obvious, so thanks in advance for the help.


You are escaping the symbols and in this case you actually don’t want to. The directions show a urlpath example with no escape codes.

So for your example link you tried to make, the following would be the correct one:

And that works in freshly-opened Firefox that I never use otherwise. (See discussion below in reply to @manics response.)

However, I think behind-the-scenes this employs JupyterLab’s workspaces to work and those may be broken at present. (BUT MAY NOT BE IF YOU TRY FRESH MACHINE OR BROWSER? See rest of this discussion chain below before you read the rest of this reply about rolling back.) For example, the example here doesn’t work. So it isn’t you. This is the example link that is underlying the launch binder badge:

If you try that, you’ll see it doesn’t work at present. I posted about this issue work workspaces being broken here and that contains the link to the issue that still appears to be open at present. I also posted about here. In that case, the person was able to roll back to JupyterLab 2 editing a Dockerfile. You should be able to specify the JupyterLab version in a requirements.txt configuration file, for example see here. I haven’t checked if that allows workspaces to work via MyBinder if you roll back to JupyterLab 2 (or earlier version of 3?) like as done here.

I suspect the problem might be with how JupyterLab uses just the domain name (?) to identify different deployments. This normally works since you’ll normally only have one server running on a host:port but fails with since you can have multiple independent JupyterLab instances.

For instance, if I go to it works, but if I launch that link again it’ll launch a second server, but I’m sent to something like lab/workspaces/auto-6. This is similar to what happens if you open another tab for the same single JupyterLab server, e.g. http://localhost:8888/lab vs http://localhost:8888/lab/workspaces/auto-y

Maybe? And maybe it is a Chrome issue? I hadn’t tried another browser yet.
I have an older version of Firefox that I never use and I just tested opening the correct link (below) in two windows at the same time.

Link from my initial response to @pdeitel , which is the link I tested with just now:

Two things shocking:

  1. That link works well to open the correct notebook in my older Firefox.
  2. I can open another instance launched from same link one in another window and it works to open the correct notebook, too, in my older Firefox.

Chrome has failed with links I’ve tried today, but I had noted I used an older demo in my reply here and workspaces were working in Chrome for that. I had thought it was because it was built long ago; however, I just tried it again in my Chrome browser and it isn’t working now. So this seems to support your theory. I had been there recently and my browser recalls and is messing up the workspace.

However, not in favor of the browser fixing things, is Jason Grout’s post here where latest Firefox seemed to mess up restoring workspaces. (Maybe that is different?)

Have you tried using an incognito/private window? That will help identify whether the existing browser state is a factor.

Just did that in my believed-to-be current Chrome and @pdeitel’s corrected link worked fine when it was in an Incognito window. That’s a nice work-around for testing when it seems to stop working.

1 Like

I actually did not escape anything. When I posted, it must have added the escapes into the URL. Very strange. I have a separate file open with the link you gave and it’s character-for-character identical to what I thought I pasted into my question–yet your link worked and mine did not.

EDIT: The problem in my original link appears to be HEAD. Switching to master corrects the problem. I generated the original base part of my link from the home page, then added the path info later.

1 Like

Thanks for the corrected link @fomightez.

1 Like

Yet another work-around…
Answering what may be a related question here, I did see that @dlukes had mentioned reloading helped get to the correct workspace and so I wondered if it would hep when MyBinder launches don’t take you to the correct notebook. Sure enough when the second Chrome browser window I had opened with the example link I used above failed to open the correct notebook, I was able to issue a hard refresh of the page (command-R on a Mac) and it then opened the correct notebook after the page refreshed.

Currently, none of these work-arounds/solutions allow the workspace loading that the ‘Try Jupyter’ JupyterLab demo uses to open properly. (The 'Try ‘Jupyter’ demo is here at Project Jupyter | Try Jupyter. If you go there and click Try JupyterLab to launch you’ll see it currently doesn’t load the notebook or panes it should. The repo backing that demonstration is here). That workspace isn’t just a specific notebook but an arrangement of panes in the workspace, including a notebook ‘Lorenz.ipynb’. And currently it is using JupyterLab 3.0.7. I have tried it in both Chrome and Firefox and don’t see this loading via MyBinder properly. And so this goes back to saying there may be an issue with workspaces and MyBinder working as I raised here. Maybe it is just more complex workspaces? If you are lucky, yours isn’t this present issue.