Closed roboneuro closed 1 year ago
Ok. Well, as of next Monday, I am working two days a week for another lab, so I will have to try and debug this issue when I can find the time between that and my other tasks/meetings the three other days. I had hoped that submitting with pre-built notebooks would speed up the submission process (as now the jupyter book build itself is broken) and that we were near it, but it looks like this will take some more time. I'll update you when I have made any progress debugging this – I probably won't have more than a couple of hours next week to start digging into this.
If @agahkarakuzu has more time available, maybe he can explore this sooner than I can
No problem @mathieuboudreau, I will also look at it. Specifically comparing the built docker image (in the registry), and a local version of yours.
@mathieuboudreau @agahkarakuzu Alright so I have tried to run the jupyter-book build content/
in several environments:
binder-registry.conp.cloud/binder-registry.conp.cloud/binder-qmrlab-2dt1-5fbook-54ed4d:330da581e4154314d693c61648bdc7cfcf3a676a
git clone -b neurolibre https://github.com/qMRLab/t1_book
cd binder
sudo docker build --no-cache --tag=qmrlab-2dt1-5fbook-54ed4d:330da581e4154314d693c61648bdc7cfcf3a676a .
All of these methods returned the same error mentioned above.
I would suggest to compare the local environment (if on your PC your notebooks are correctly executed?) VS the environment inside the Docker (you can pull binder-registry.conp.cloud/binder-registry.conp.cloud/binder-qmrlab-2dt1-5fbook-54ed4d:330da581e4154314d693c61648bdc7cfcf3a676a
).
Here is a 10 minute screen-captured demo of my IR notebooks all executing correctly on MyBinder with my current setup on the neurolibre
branch: https://youtu.be/1oCLPyCht-Y
I conclude two things from this:
1 - My Dockerfile is well-designed to execute my notebooks from within a built container image. 2 - My notebooks execute correctly and generates the Plotly figures.
Also, because the Jupyter Book built correctly before with the notebooks pre-executed,
3 - My Jupyter Book config file is well-designed to build the book using our previous method.
The problem then must be related to Jupyter Book/RoboNeuro/NeuroLibre.
My repo follows the guidelines as described in the NeuroLibre submission documentation.
Here is a direct link to my image on MyBinder so you can test for yourself: https://mybinder.org/v2/gh/qMRLab/t1_book/neurolibre?urlpath=lab
I am still open to reverting to our previous method, where the Jupyter Book was built using pre-executed notebooks. But that's not my call, as I am the author in this case and not one of the testers/editors.
Can you share the results from pip freeze
in the Dockerized execution environment, @mathieuboudreau ? I'm particularly interested in your nbclient
version.
Here's the output @emdupre:
Thanks, @mathieuboudreau ! That's quite an old version of jupyter-client
, and this error should have been resolved as of 6.1.3. I'm wondering if this is occurring because of the interaction of the pinned v unpinned dependencies and the chosen pip solver. The docker logs suggest as much :
I'm currently not well set-up to do extensive testing, but I imagine that the problem is that your current requirements conflict with something JB needs in its build process (likely jupyter-client
, or nbclient
). This may not affect your notebooks themselves if you don't use that dependency in your execution.
As a first pass, could we update the pip solver ? Or, if that's not possible, could we unpin the versions for nbconvert
and jupyter-lab
and let pip solve to its preferred version ?
The only main concern is that, if I remember correctly from 2 years ago, SoS (or at least, the version I'm using) was only made compatible with a specific range of jupyter-lab
, such that the SoS kernel might not work if I upgrade that. We can certainly try to unpin these, but it might bring on other issues.
Maybe a separate branch to test these on would be appropriate?
We could also definitely update the pip solver.
Ok @emdupre, I made your requested changes in the neurolibre-unpin
branch.
@roboneuro generate nl-notebook from branch neurolibre-unpin
Attempting NeuroLibre notebook compilation from custom branch neurolibre-unpin. Reticulating splines etc...
:seedling: We are currently building your NeuroLibre notebook! Good things take time :seedling:
:seedling: We are currently building your NeuroLibre notebook! Good things take time :seedling:
OK, this failed ! I think because of the compute time. I'll look into this more and try to give a more graceful failure soon.
Logs:
EDIT: and we're seeing the same failure on the preview page, just as confirmation that these two are now in sync !
MyBinder was powerful enough to build it: https://mybinder.org/v2/gh/qMRLab/t1_book/neurolibre-unpin?urlpath=lab
However, as I expected, the updated version of JupyterLab and nbconvert rendered the SoS kernel incompatible, as it's not showing up anymore. Meaning, the notebooks won't be able to execute with this current setup, even if we fix the slow/underpowered NeuroLibre's BinderHub setup that's preventing the build to complete there.
@mathieuboudreau The notebooks execute ok in the binder environment, but here is what I get running jupyter-book
inside the binder terminal (MyBinder). This indeed could be related to the jupyter book rendering itself ?
I also tried to execute separately with jupyter nbconvert --to notebook --execute content/01/IR_BenefitsAndPitfalls.ipynb
(instead of jupyter-book build content
, and the error seems different:
@emdupre Not sure why the error page is empty, because the log file exists here:
https://neurolibre-data.conp.cloud/book-artifacts/qMRLab/github.com/t1_book/baeab5445fe59a151c896c7359e44f7b45190c80/book-build.log
As we can see, there is still the same issue as above with the jupyter-book build
.
Yes, both the preview page and the roboneuro-bot didn't have a nice mechanism to display time-out errors. That's something that can be added !
Ok it is not clear for me what @mathieuboudreau issue was with the logging from RoboNeuro. Was it because of the empty output of the page ? Or because you did not receive any mails from RoboNeuro ? In any case the empty output on the page is problematic and confusing for the end user (we already raised that issues few weeks ago), but we can discuss it fast tomorrow.
I've removed all restrictions in my pip version (e.g. sos, plotly, jupyter book, nbviewer, etc). I've also updated the Docker image that we're pulling from a fixed version to latest.
I think I have three things to resolve now
[x] Update my jupyter book format, toc, and folders, to the latest version (as of today, 0.12.0)
[x] Fix a new error/warning introduced when first executing the Octave cell/qMRLab startup
[x] Fix the new background/formatting issues with the newer versions of Plotly
One last bug I found happening occasionally (not all the time), is that sometimes the transfer of data/environment from Octave to Python failed, but it happens sporatically (rerunning will work for some reason). Maybe it's an issue that it's running the cells too quickly.
After all of this is done, I don't think I can do more improvements as every dependency will be up to date and the simulations have been drastically shortened in time. If RoboNeuro/NeuroLibre still doesn't function correctly during the submission of this notebook after all these changes, then either 1) changes will need to be made on the NeuroLibre/RoboNeuro side to accommodate our book's needs, or 2) we close the submission of this book.
I'll post again once the remaining to-do list is complete.
p.s. the branch that I'm working on now is neurolibre-unleashed
I've updated my TOC (058ae1a) and attempted a Jupyter Book build, which fails while executing the notebooks.
I find it difficult to interpret these logs. The main part seems to be:
File "/opt/conda/lib/python3.9/site-packages/sos_notebook/converter.py", line 152, in from_notebook_node
resources['output_extension'] = '.sos'
TypeError: 'NoneType' object does not support item assignment
However, SoS works fine when executing the notebooks inside Jupyter Lab. So my gut tells me that this is an incompatibility between Jupyter Book's jupyter notebook execution kernel setup and SoS. I have to manually add the SoS kernel in my environment during installation (https://github.com/qMRLab/t1_book/blob/058ae1a8be743c4dab14b6f32156084f36071b3d/binder/Dockerfile#L67); I don't know if this added kernel seen by Jupyter Book's environment.
I don't know if this is something I can resolve on my end without hacking JupyterBook's backend.
Open to suggestions.
I've opened an issue on Jupyter Book for this problem here https://github.com/executablebooks/jupyter-book/issues/1519.
I've opened an issue on Jupyter Book for this problem here executablebooks/jupyter-book#1519.
Hope that this will help :)
In the meantime we can still fallback to pre-executed notebook content stored in repo if we want to list the book on neurolibre ? We can also try to get execution cached content using repo2data, I have a workflow in mind lmk.
In the meantime we can still fallback to pre-executed notebook content stored in repo if we want to list the book on neurolibre ?
I've been asking for this since last month, but @pbellec was strongly against I think? Or was it you? Regardless, I've invested time making my repo compatible with the Jupyter Book auto-execution methods I was asked to do, so I'd like those efforts and work hours not have gone to waste, and move in that direction (auto execution) if possible.
As I highlighted, this could be a temporary (and faster) solution to have your submission listed on the NeuroLibre website. At this stage if we have no other solutions than using pre-executed content, it is better than nothing I think (regarding also what Nikola raised at our last meeting). But definitively not my choice, just throwing an idea...
As I highlighted, this could be a temporary (and faster) solution to have your submission listed on the NeuroLibre website. At this stage if we have no other solutions than using pre-executed content, it is better than nothing I think (regarding also what Nikola raised at our last meeting). But definitively not my choice, just throwing an idea...
I agree - that's why I was suggesting this last month –knowing how difficult the transition to the auto-executed notebook was going to be for this setup– but got denied. I even mentioned it at yesterday's meeting too, if I recall, but no one signalled me that they had changed their minds on allowing this workflow again, so last night and today I worked on converting my repo to being compatible with the required Jupyter Book auto-execute workflow I was asked to do.
@pbellec please chime in, I don't want to spend more time doing unnecessary/unusable work in this issue.
Just my opinion: What you are doing is something needed (you don't lose your time...), and publishing a pre-executed content is independent from trying to re-build the book. It does not change the fact that it needs to be reproducible/re-executable at one point. In recap, I am just proposing an alternative, independent path for the renewal.
In recap, I am just proposing an alternative, independent path for the renewal.
This submission is no longer needed for the renewal, because it is working here on the old NeuroLibre website: https://www.neurolibre.com.
In recap, I am just proposing an alternative, independent path for the renewal.
As a user, I just wish that you would have been open to this idea last month when I first submitted the book this way, and then warned of the delay that doing it otherwise would cause.
This submission is no longer needed for the renewal, because it is working here on the old NeuroLibre website: https://www.neurolibre.com.
Oh ok, my understanding was that it was super urgent because of the renewal!
As a user, I just wish that you would have been open to this idea last month when I first submitted the book this way, and then warned of the delay that doing it otherwise would cause.
Indeed I could not predict the fact that we would face so much issues when trying to re-execute it, I am not aware of the jupyter-book ecosystem... And I did not know that this submission was not re-executed after few months if not years (I actually highlighted the fact that the notebook execution was off) :(
The problem was not with how long the notebooks had been executed, it was 1) due to changing the directory structure needed to comply with Neurolibre which caused a bug when adding the necessary paths in the notebooks, and 2) what was needed to get the book building with Jupyter Books auto execute function.
Opened an issue on SoS's repo since the Jupyter Book folks are not responding on their end.
I also fixed the three issues mentionned above,
@pbellec here is a screencaptured walkthrough from starting MyBinder to executing every cell in every notebook, in under 20 minutes. https://www.youtube.com/watch?v=_HVnz34UaF0
All images compile and no errors occur.
@ltetrel Since having to upgrade nbconvert, Jupyter Book, and SoS to the latest versions, now even building the book with pre-executed notebooks fails. See this screcaptured walkthrough: https://www.youtube.com/watch?v=sLPU1FzBue8
So this shortcut is no longer an option for this submission - there is a bug in either the latest version of Jupyter Book or SoS, or they are simply no longer compatible tools together like they used to be in their older versions when we built this book that is still stable and fully functioning.
Did you try an older version of jupyter book? I know this https://github.com/ltetrel/nha2020-nilearn could not build for latest version of jb, so I fall back to 0.10.
@mathieuboudreau first of all, huge thanks for your patience - I've been under deadlines for a couple of days and only catching up now. The primary value proposition for neurolibre is re-executable content. So I re-iterate that we need to take that submission to a point were we can re-execute the code.
If I understood correctly, at this stage SoS has become incompatible with Jupyter Book, and you opened issues with both projects. There is nothing more we can do. I've noted that the last SoS release was two years ago, so it makes sense that we are running into issue with the recent major iteration of jupyter book. I love the idea of showcasing multiple languages inside one book - but it looks like we are running out of options. Or at least it is out of our control.
If we want to move forward with this rapidly, you could turn the simulation to a stand-alone repo with a dependency on octave only. You can make that repo easily reproducible through a command line. Save the outputs of the simulation on zenodo. And then start the jupyter book from the zenodo data using repo2data (adding link to the octave repo), with python-only dependencies. For heavy processing, this would anyway be the best (and only) approach. In that sense it would be a very useful example for future users.
If I understood correctly, at this stage SoS has become incompatible with Jupyter Book
It's unclear to me at the moment if it's SoS that has become incompatible with Jupyter Book, or Jupyter Book that has become incompatible with SoS.
If we want to move forward with this rapidly, you could turn the simulation to a stand-alone repo with a dependency on octave only. You can make that repo easily reproducible through a command line. Save the outputs of the simulation on zenodo. And then start the jupyter book from the zenodo data using repo2data (adding link to the octave repo), with python-only dependencies. For heavy processing, this would anyway be the best (and only) approach. In that sense it would be a very useful example for future users.
If we go this route, I'd rather just save all simulation outputs that are done in Octave, delete all qMRLab code and dependencies, and simply load and plot data in Python. This should reduce the Docker image from about 4 GB to under 1GB, which is something Loic wants to see in submissions. The only disadvantage is that the only things the notebooks would do is load and plot data, and not really do anything else (i.e. users won't be able to reproduce the results/plots or modify them), but at least we could say that the submission works in NeuroLibre just for the sake of saying it does.
at least we could say that the submission works in NeuroLibre just for the sake of saying it does.
I feel your frustration. I have learned the hard way the tension between fancy features (here, multi-language support) and robustness/maintainability, and have grown to value much more the later. And to re-iterate: jupyter book are simply not a good fit to share long computations. It makes more sense to have a combination of modular, reproducible repos with jupyter book as a last layer for visualizations and relatively light analyses. If the octave repo is well done, it will be an integral part of the work - simply expose it as a submodule, and the work will be fully reproducible. Just not done with a one-size-fit-all technology.
My frustration mostly comes from the fact that this book with all its features has been already created and sustained with strong stability for 3 years already, here: http://qmrlab.org/t1_book/intro, and after spending 2-3 months trying to make it compatible with the automated pipeline necessary to publish it in NeuroLibre, I'm asked to "dumb down" my book significantly, which is creating an even greater workload to me, the user, with no additional benefits (since my I'll only desire to share my full-featured book anyways). If NeuroLibre had not been so ambitious with its automation goals, I feel that a set of reviewers could have simply reviewed my already prepared full-featured Jupyter Book and migrated it into your servers in a matter of days/weeks instead of months. I think if external users are asked to delete the heart of their submitted notebooks (simulations/fitting/etc) in order to just plot the data in the future, they might opt-out of submitting to NeuroLibre in order to simply self-publish through GitHub or their websites, as we have done.
The root cause here is lack of support for SoS in the recent jupyter book. It sucks that we ran into an incompatibility issue, sure. I don't think this calls into question the entire neurolibre workflow.
Another option would be to have one notebook with the octave code (and an octave kernel) and one notebook with the python code (with a python kernel, and starting from a pregenerated data archive).
This way users can re-execute all parts of the analysis, just not chain them like SoS can.
@roboneuro generate nl-notebook from branch neurolibre-plots-only
Attempting NeuroLibre notebook compilation from custom branch neurolibre-plots-only. Reticulating splines etc...
:seedling: We are currently building your NeuroLibre notebook! Good things take time :seedling:
@roboneuro generate pdf from branch neurolibre-plots-only
Attempting PDF compilation from custom branch neurolibre-plots-only. Reticulating splines etc...
Submitting author: !--author-handle-->@mathieuboudreau<!--end-author-handle-- (Mathieu Boudreau) Repository: https://github.com/qMRLab/t1-book-neurolibre Branch with paper.md (empty if default branch): main Version: v1.0.0 Editor: !--editor-->@agahkarakuzu<!--end-editor-- Reviewers: !--reviewers-list-->@agahkarakuzu<!--end-reviewers-list-- Reproducible preprint: Pending Repository archive: Pending Data archive: Pending Book archive: Pending Docker archive: Pending
Author instructions
Thanks for submitting your paper to NeuroLibre @mathieuboudreau.
@mathieuboudreau if you have any suggestions for potential reviewers then please mention them here in this thread (without tagging them with an @). In addition, this list of people have already agreed to review for NeuroLibre and may be suitable for this submission (please start at the bottom of the list).
Editor instructions
The NeuroLibre submission bot @roboneuro is here to help you find and assign reviewers and start the main review. To find out what @roboneuro can do for you type: