Image 2lmrrh8f.gra7.container-registry.ovh.net/mybinder-builds/r2d-g5b5b759atlas-2doutreach-2ddata-2dtools-2dnotebooks-2dcollection-2dopendata-40f4f5:408c95a8dee697c4a3168aa73e88d80006abf424 for user atlas-outreach--ection-opendata-k4oq11su took too long to launch
I’ve thrashed around with a few things I found via google and on this forum, but I haven’t found a good solution. Is there a good way to debug these sorts of issues short of guess-and-check? Anything I can test locally with more verbose output, for example? Or best practices that I should check if I’m following?
Medium-term, I’m hoping to clean up our environment substantially, but I’d like to get these binders up and running in the meantime if possible.
What I see is that the session tries to start but nothing works in it because you environment.yml file isn’t used. (By nothing works, I mean I specifically cannot get any flavor of Jupyter to open, even hand-editing the URL to something that normally works.) Instead the Dockerfile that doesn’t follow the configuration guidelines is used because as covered in the documentation here:
“If a Dockerfile is present, all other configuration files will be ignored.”
That Dockerfile interfering results in a session that not useable.
Presumably that Dockerfile is there for some other use in your work or how you share it with others and so cannot easily be moved or adapted. Fortunately, you can easily get around this by making a binder directory. I forked you repo and did that here and then put the environment.yml for the MyBinder session in that. Much of this is covered in more detail in the first five paragraphs of ‘Build completes successfully then “Binder Inaccessible”’ here, which had similar issues.
Try launching your test notebook in sessions served by my fork by clicking here. You’ll see it works in that by skipping the first cell, I was able to run the rest of that HZZAnalysis.ipynb notebook successfully, getting the fancy plot as the output at the last code cell (15th code cell in my run).
So you should be able to make a binder directory in the root of your own repository and place a copy of your environment.yml in there. (Or simply move it in there if you don’t need it in root?) And then things should work to give you a session that works. I made some other small changes in the environment.yml file in my fork that you’ll want to test if they are necessary for your needs or not. For example, when I tried to run HZZAnalysis.ipynb, it said aiohttp wasn’t installed and so that was added.
Amazing, thank you!! If I may, how did you spot that? Was it just “I know this is a mistake that people make”? Or was there something in the log file I should’ve spotted?
I knew from helping people in the past and comparing your Dockerfile to what is appropriate.
The issue that an inappropriate Dockerfile can interfere is emphasized in the documentation, as I pointed out. Because there can be an appropriate Dockerfile & what is appropriate can change with time, it isn’t really something that the build log will show.
Got it — thanks! (I was hoping somewhere in the build log it would say “Pulling configuration log from…” and clarify what file in the repo it was using. Might be a nice feature for the distant future?).
Well I think it is clear in the build log that it isn’t using the environment.yml as you expected. I know from building several times yesterday that it was stated, I think around step 39 of 62, it is using binder/environment.yml.