Repository navigation
6.1.2 breaks the aafigure extension, it worked in 6.1.1 #11117
Copy link
Copy link
Closed
Milestone
Description
Describe the bug
The latest version of sphinx, 6.1.2, breaks the aafigure extension, it makes it try to copy the src folder instead of the actual images I think.
Traceback (most recent call last):
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\builders\html\__init__.py", line 778, in copy_image_files
copyfile(path.join(self.srcdir, src),
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\util\osutil.py", line 97, in copyfile
shutil.copyfile(source, dest)
File "C:\Users\Victor\miniforge3\lib\shutil.py", line 265, in copyfile
with open(src, 'rb') as fsrc, open(dst, 'wb') as fdst:
PermissionError: [Errno 13] Permission denied: 'C:\\path-to-docs\\src\\.'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\cmd\build.py", line 284, in build_main
app.build(args.force_all, args.filenames)
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\application.py", line 347, in build
self.builder.build_update()
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\builders\__init__.py", line 311, in build_update
self.build(to_build,
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\builders\__init__.py", line 380, in build
self.finish()
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\builders\html\__init__.py", line 685, in finish
self.finish_tasks.add_task(self.copy_image_files)
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\util\parallel.py", line 38, in add_task
res = task_func()
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\builders\html\__init__.py", line 781, in copy_image_files
logger.warning(__('cannot copy image file %r: %s'),
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 1812, in warning
self.log(WARNING, msg, *args, **kwargs)
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\util\logging.py", line 127, in log
super().log(level, msg, *args, **kwargs)
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 1844, in log
self.logger.log(level, msg, *args, **kwargs)
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 1512, in log
self._log(level, msg, args, **kwargs)
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 1589, in _log
self.handle(record)
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 1599, in handle
self.callHandlers(record)
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 1661, in callHandlers
hdlr.handle(record)
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 948, in handle
rv = self.filter(record)
File "C:\Users\Victor\miniforge3\lib\logging\__init__.py", line 806, in filter
result = f.filter(record)
File "C:\Users\Victor\miniforge3\lib\site-packages\sphinx\util\logging.py", line 427, in filter
raise exc
sphinx.errors.SphinxWarning: cannot copy image file 'C:\\path-to-docs\\src\\.': [Errno 13] Permission denied: 'C:\\path-to-docs\\src\\.'
How to Reproduce
index.rst with empty aafigure directive + conf.py with the extension is enough to trigger the error:
.. aafig::
extensions = ["aafigure.sphinxext"]
Environment Information
Platform: win32; (Windows-10-10.0.22621-SP0)
Python version: 3.9.7 | packaged by conda-forge | (default, Sep 29 2021, 19:15:42) [MSC v.1916 64 bit (AMD64)])
Python implementation: CPython
Sphinx version: 6.1.2
Docutils version: 0.19
Jinja2 version: 3.0.3
Pygments version: 2.14.0
Sphinx extensions
["aafigure.sphinxext"]Additional context
I wonder if its this PR that causes it? #11100
Reactions are currently unavailable
Activity
ksunden commentedon Jan 9, 2023
Matplotlib's sphinx extension is also similarly affected (not sure yet if it is the same cause, we are getting assertion errors in our test suite rather than direct errors raised by sphinx, but it is new with 6.1.2)
Ours does seem to be affected by #11100, which causes additional
.pyfiles to appear in theimagesfolder (in addition to the_downloadsdirectory) and we assert that only one file with that name exists.ksunden commentedon Jan 9, 2023
Okay, my digging has shown that #11100 changed from using
self.imagestoself.env.imagesin the builders (see the html builder for example).self.imagesis commented as "images that need to be copied over", but seems to no longer be used for this purpose as of #11100.self.imagescontains a narrower set of items extracted fromself.env.imagesinBuilder.post_process_images, which (among some other things), seems to cut out anything that is not a "supported image type" (such as apyfile for matplotlib or a directory for aafigure).For aafigure, this means trying to copy a folder by opening it as a file, which is an PermissionError. For matplotlib, this means that a py file gets copied where it hadn't been before and our tests catch that change.
Arguably, the proper fix is to prevent unsupported image types from entering
self.env.imagesin ImageCollector.The logic around
guess_mimetypeincollect_candidatesends up getting a "mimetype" of"image/x-py"for python files since it is pre-wired to treat everything it sees as an image type.AA-Turner commentedon Jan 9, 2023
The change to .env.images was done to allow more parallelism. If there are changes Sphinx should make here, would you be able to open a PR? I may have time to review it but due to other commitments I won't be able to look at this myself before May-ish.
A
Pin sphinx != 6.1.2
jfbu commentedon Jan 10, 2023
The following patch (on 6.1.x) appears to fix the
aafigureproblem:(the comments I added are for my own education and not quite precise; thanks @ksunden for your analysis, I have not checked the
matplotlibcontext, only tested withaafigure)PS @ksunden do you happen to have a small project showing the issue with
.pyfiles?AA-Turner commentedon Jan 10, 2023
I have released v6.1.3 which should fix this by reverting the parallel image changes.
A
ksunden commentedon Jan 10, 2023
https://gist.github.com/ksunden/1b726225cbc93e65c7e478fda4dd5a1f
Here is a gist with a fairly minimal conf/Makefile extracted from our tests (still using the mpl extension, so not minimal in that dimension, but outside of that it is fairly minimal) (the makefile was edited to create an empty
_staticfolder because there was a warning without it but it is otherwise unused and gists can't have folders)It builds without warning/error, but the
.pyfile generated from theplotdirective source ends up in thebuild/html/_imagesdirectory, which is unexpected.I will note that mpl's sphinx extension was recently modified in matplotlib/matplotlib#24205 and undoing that change does actually fix our tests, but leaves many files in
build/htmldirectly (but does not treat py files as images).viblo commentedon Jan 10, 2023
I can confirm that v6.1.3 with the reverted changes fixes the aafigure issue for me.
Thanks for the quick action!
jfbu commentedon Jan 10, 2023
Thanks @ksunden for very small example indeed (I used the bare sphinx-quickstart Makefile). I had not seen the issue when trying directly earlier because I was using Matplotlib
3.6.2(see below).The
:show-source-link:is not in the last release3.6.2of matplotlib so I installed from the git clone the current dev. Then I realized I reproduced the issue with Sphinx6.1.2and latest Matplotlib-dev also without using the:show-source-link:option so I removed it from then on. (as far as I could tell later this option allows to remove the link to the source code, but by default it is there and was already there with earlier matplotlib).With
3.7.0.dev1292+ge0dc18d51e5.3.0:6.1.2:6.1.3With matplotlib
3.6.2on the other hand all versions of Sphinx act the same5.3.0and6.1.2and6.1.3The
source codelink next to the plot rendering appears to work fine but I checked only with Sphinx6.1.3and either Matplotlib3.6.2or the dev version which puts the.pyfile in_downloads/rather than directly under$BUILDDIR/html. TheBuilding editable for matplotlib (pyproject.toml) ... donefor install from git clone (with or without editable) is a bit longish and I was too dumb to think of creating one newvenvto do it there rather than alternating withpip install matplotlib==3.6.2.In summary it seems users of Matplotlib will not be hit by this Sphinx
My [patch above on Sphinx 6.1.2](https://github.com//issues/11117#issuecomment-1376936102) which fixed the aafigure problem is irrelevant to stuff with ``.py`` files.6.1.2issue because it is not seen with Matplotlib3.6.2but requires the dev version. And Sphinx has already released6.1.3today.jfbu commentedon Jan 10, 2023
Closing this as
6.1.3release resolved the problem via 2a7c40d.Relates #11100.