-
Notifications
You must be signed in to change notification settings - Fork 207
[sphinx 1.5] _gdbm.error No such file or directory #186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I do get an error as well on your scikit-image PR branch, but with an error which is a bit more informative (if you follow the traceback the stack trace is very similar):
|
It could well be related to #115. I seem to remember that scikit-image had some specific config that was different than the default. I am guessing we should try to create searchindex.dat in |
@lesteve Thanks for your quick reply. Why would you like to create a file in source/* during a build procedure? This would go against the idea of the configuration to generate all the files in a separate directory (namely build), no? |
I am not sure why but this is definitely what the code is doing. IIRC we are using the default settings in sphinx-start and we don't have this distinction of build and source folders. This is what #115 was talking about indeed, @emmanuelle was saying:
Full disclosure this is the kind of sphinx details that I have no clue about, if you have references that explain this a bit I am interested. It seems like we fixed #115 through a kludge and we need to understand this build/source folder more if we want to support it going forward. |
If related to #115 then I think scikit-image has an extra patch to handle this case that got washed in your update @sciunto. Look at line scikit-image/scikit-image@73ec69c#diff-70a0de33ac06adccedd71571a25f2b60L320 This issue of configuring sphinx gallery for different directory structures or launching the build from a directory different that the default one is not completely supported by the gallery yet. I started a PR #133, to go fix this but got way more complicated that it should have. I'll shall revisit it again. |
@sciunto not sure how you update your sphinx-gallery copy but using the copy_sphinxgallery.sh script rather than doing it manually is probably a good idea (copy_sphinxgallery.sh should be in your PATH if you did |
@lesteve sphinx-gallery is shipped with scikit-image. our copy is supposed to correspond to upstream (we submit patches as needed). From what @Titan-C said, it seems that some of our modifications have not been merged in your branch. I ping @emmanuelle as she set up sphinx-gallery and I'm pretty sure to be the first one who modified that since then. Our procedure is not optimal, but I think there was a good reason behind it (like you didn't released modifications that we needed). @emmanuelle Am I right? |
Just to be clear, scikit-image is a first class citizen as far as sphinx-gallery is concerned, so do not hesitate to open issues if you encounter problems or submit your patches as PRs. We'll do our best to tackle them! |
@lesteve Yes, normally, our policy is to submit all our modifications to upstream :) Let's wait for @emmanuelle 's answer, she is the expert. |
After some discussions with @emmanuelle here: scikit-image/scikit-image#2395 It seems that it is a regression on your side. All our modifications have been submitted and merged to master when we integrated the gallery for the first time. |
Indeed I can see that your sphinx-gallery copy is sphinx-gallery 0.1.7 without any modification. Hmmm we really need to have better test coverage for this. |
Yes. We don't have testing for building the gallery out of our default structure. From what I see is that scikit-image when propagating their changes to Sphinx-gallery, we are missing their change of directory when resolving links, which is done after building the gallery and all html |
@sciunto this seems to fix (tested on your scikit-image PR): diff --git a/sphinx_gallery/docs_resolv.py b/sphinx_gallery/docs_resolv.py
index b2757d2..0ee5120 100644
--- a/sphinx_gallery/docs_resolv.py
+++ b/sphinx_gallery/docs_resolv.py
@@ -447,6 +447,9 @@ def embed_code_links(app, exception):
print('Embedding documentation hyperlinks in examples..')
gallery_conf = app.config.sphinx_gallery_conf
+ # cd to the appropriate directory regardless of sphinx configuration
+ working_dir = os.getcwd()
+ os.chdir(app.builder.srcdir)
gallery_dirs = gallery_conf['gallery_dirs']
if not isinstance(gallery_dirs, list):
@@ -454,3 +457,6 @@ def embed_code_links(app, exception):
for gallery_dir in gallery_dirs:
_embed_code_links(app, gallery_conf, gallery_dir)
+
+ # Back to initial directory
+ os.chdir(working_dir) @Titan-C this is because |
@lesteve as I wrote earlier. scikit-image has this extra patch on their codebase that changes directory in I have no good memory why we did not propagate the hack from As a matter of implementation Sphinx does not change directories during build, but we do. We change once when generating the gallery to the source directory. And while building each example to the example location directory. Finally we return to Sphinx workdir. Then we need (because is not implemented yet) in the |
OK that is what you said earlier, sorry about that, it was not very clear to me where this diff was coming from. I guess the short-term solution is for scikit-image to restore this change in embed_code_links and for sphinx-gallery to integrate it in master. |
I did a new PR #190 which shall address this. Drop the dir changing during build and link embedding. Dirs will only be changed when running the example. For scikit-image I have propagated #190 on top of their PR scikit-image/scikit-image#2395. I think it shall build but travis is still on it (https://travis-ci.org/Titan-C/scikit-image/builds/185812316) |
Looks good so far :) Thanks for being so responsive! |
Fixed in #190 |
@Titan-C It looks like there is still some issues... I updated sphinx-gallery to 0.1.7.
I copy paste the log file. Travis job is here: https://travis-ci.org/scikit-image/scikit-image/jobs/183569010
The text was updated successfully, but these errors were encountered: