blink1073
commented
10 months ago Hi @matteobachetti, to be clear, it works with 7.13.1? I don't see anything in the 7.14 release itself that looks relevant.
Open matteobachetti opened 10 months ago
blink1073
commented
10 months ago Hi @matteobachetti, to be clear, it works with 7.13.1? I don't see anything in the 7.14 release itself that looks relevant.
matteobachetti
commented
10 months ago Yep, you can see here that nbconvert fixed to <7.14 (it uses 7.13.1) does not produce the issue. But I'm not sure there are no other dependencies that are influenced by this. https://github.com/StingraySoftware/stingray/actions/runs/7388419796/job/20099216748
matteobachetti
commented
10 months ago @blink1073 is there a way to debug this? If I could access the rst files produced by nbconvert, for example, I could look at exactly what lines are producing the raw directive.
blink1073
commented
10 months ago Unfortunately not, based on looking at https://github.com/spatialaudio/nbsphinx/issues/620.
What you can do is test the specific commits:
nbconvert: git+https://github.com/jupyter/nbconvert.git@a3a069c9a10bb011911166c0f84b9edb1fef305d
The commits we're interested in are:
15625319f6bd7917df8ec891795411554e0015bd
a3a069c9a10bb011911166c0f84b9edb1fef305d
ece13fd22d96fda9cde06534e265bc5fe3fc4c80
0f17b3069d320565af12a4a12da7d9ce3c18dac4
b1715cdae9b4b51c1797a63a7045660145d36aac
danking
commented
9 months ago We ran into this as well. I can't seem to replicate on my Mac, it only occurs in Linux containers in our CI system. We pin the requirements, so, modulo OS differences, I should have the same packages as the CI system.
Example failing notebook: https://github.com/danking/hail/blob/update-deps/hail/python/hail/docs/tutorials/06-joins.ipynb Our pinned-requirements: https://github.com/danking/hail/blob/update-deps/hail/python/dev/pinned-requirements.txt
The code we run follows, but I've updated the paths to make sense from the root of the Hail repository. The Makefile in hail/python/hail/docs is here.
set -o pipefail
export SPHINXOPTS='-tgenerate_notebook_outputs'
make -C hail install python/hail/docs/change_log.rst
make -C hail/python/hail/docs BUILDDIR=_build clean htmlI ran the code from #620 to generate RST from the ipynb and then copied that RST file into my docs and built the docs (on my Mac, which hasn't failed yet) and it seems to have built fine. The generated RST is here.
I'm a bit at a loss about how to move forward.
danking
commented
9 months ago Could things like this be an issue? I'd have expected the text to be indented.
namurphy
commented
9 months ago We had a similar problem come up over at XRTpy on this notebook and this other notebook, neither of which have any raw cells.
The error happened on both ubuntu-latest and macos-latest, but I was able to get rid of it by setting nbconvert < 7.14 in https://github.com/HinodeXRT/xrtpy/pull/215.
This was the specific error that started showing up a bunch of times:
/Users/runner/work/xrtpy/xrtpy/docs/notebooks/data_analysis/Deconvolving_XRT_images.ipynb:129: ERROR: Content block expected for the "raw" directive; none found.Thank you!
mgeier
commented
9 months ago https://github.com/spatialaudio/nbsphinx/issues/620#issuecomment-1003598213 shows how to get the intermediate reST representation.
With an older nbconvert it looks something like this:
.. raw:: text
0%| | 0/6 [00:00<?, ?it/s]With a newer nbconvert, the status line starts with a '\x0d' character, a.k.a. "carriage return".
This seems to confuse the reST parser, because it messes up the indentation.
When copy-pasting it here, it get's messed up in a similar way (but apparently the actual carriage return character doesn't survive copy-pasting):
.. raw:: text
0%| | 0/6 [00:00<?, ?it/s]I'm not sure if nbconvert should remove that character from its output, but if not, I guess this has to be ignored in nbsphinx.
Note that I have not executed the notebook, I have used the pre-executed Check dead time model in Stingray.ipynb, which looks like this:
"outputs": [
{
"name": "stderr",
"output_type": "stream",
"text": [
"\r",
" 0%| | 0/6 [00:00<?, ?it/s]"
]
},
{
"name": "stdout",
"output_type": "stream",
"text": [
"INFO: Calculating PDS model (update) [stingray.deadtime.model]\n"
]
},Ok, so it seems a problem with outputs containing an advancement bar from tqdm. Probably a good idea to ignore that carriage return, or to transform it in a new line maybe? Thanks for tracking this down!
mgeier
commented
7 months ago @blink1073 wrote:
Hi @matteobachetti, to be clear, it works with 7.13.1? I don't see anything in the 7.14 release itself that looks relevant.
I used git bisect to find that the culprit is ece13fd22d96fda9cde06534e265bc5fe3fc4c80, a.k.a. #2089, created by @ryan-williams.
It would be great if the original coalescing behavior could be restored.
~Maybe it's just a matter of moving the coalescing back to after the executing?~
mgeier
commented
7 months ago It looks like coalescing streams was originally enabled for the reST exporter and it was disabled in #2089.
This should fix the regression: #2142.
matteobachetti
commented
7 months ago Thanks @mgeier!
mgeier
commented
6 months ago nbconvert v7.16.4 has just been released and it should fix this problem. Can someone please confirm?
In Stingray, we build documentation from a bunch of rst files and a number of notebooks. It usually works quite well, but today I'm having errors like the ones in the build below:
https://github.com/StingraySoftware/stingray/actions/runs/7384306812/job/20086984844#step:8:511
The critical message is the following:
However, I don't know where this raw directive is, it's probably in the rst file that is being produced internally from the notebook. The errors disappear if I fix the nbconvert version to <7.14.
Thanks in advance for any help