-
Notifications
You must be signed in to change notification settings - Fork 131
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
Feature request: Auto-execute if locally dependent file is changed #87
Comments
I'm sure there are a million things that are more urgent, but this is definitely an interesting proposal. BTW, I love your use of the diaeresis, I haven't seen that before! I think we should separate two things more clearly:
I think we could definitely work on the first, I'm not so sure about the second. Also, note that Sphinx already stores state between invocations. Should we use this state or create our own? Or both? Another question is if this state should be only valid on a single machine, of if it should be shared between different users and machines. The problem with storing the dependencies in the notebook metadata is that when a cell is deleted, it might leave obsolete dependency information. Apart from that, I think this would make the auto-execute heuristics less clear to the user. Maybe people would be surprised if their (probably long-running) notebook is executed only because some file on their hard disk had changed. Also, as I just realized while writing this comment, in your motivating case you wouldn't need to use "auto", you could just use the "always" setting and it would still only be executed when something changes (since Sphinx wouldn't parse it again anyway). I don't know if a separate preprocessor would make sense, but this could be built into the preprocess() method of the Specifically, the preprocessor could put any dependency information (probably a list of file names) into the With this:
The list of dependency files might be quite large. I guess e.g. plotting something in matplotlib will read many source and data files. But since this list is only stored temporarily by Sphinx, the number of files shouldn't be a problem. |
re partial execution: I think that's going too far. But anyway, such a thing should not be discussed here but rather at Initially, I was thinking about an "execute" metadata per cell, but then I simply went with the |
@mpacer Any more thoughts? Comments? |
Haven't thought about it a lot since the New Year, but I'll read over this over again sometime over the next few days and try to think about steps forward. |
So I'm guessing this is a pretty much impossible feature request, but I was running into a tiny bug in responding to jupyter/nbconvert#500 and testing the resulting docs.
I changed the
template_structure.html
file and ranmake clean
but nothing was appearing in the resulting built docs.I noticed pretty early on that this html was being embedded within another page, which I figured shouldn't be a problem if it was being "included" in some way.
Eventually I realised that it was a
.ipynb
file that was displaying it withAnd in looking into nbsphinx's execution syntax, it was not re-executing the notebook (even though this dependency changed) because the notebook did have output and so it didn't trigger the auto rebuild.
It would be nice if it would be able to detect that a dependency exists and then reëxecute the notebook when that is needed, not only when there are no outputs.
How the notebook/nbconvert could make this more feasible
That would probably be easier if we were to store a list of file-system dependencies that are required by the notebook (maybe saving them in the metadata when executing the command that created the dependency). Though that amount of inspection is probably overkill for the average use case, it might be possible to have an nbconvert preprocessor that does something like this and returns the notebook in place with the relevant metadata.
Aside on partial execution
Since we're talking about pipe dream features, if you were able to do this, one thing that might make this even more cute and efficient would be to only execute up to latest cell whose dependencies have changed. I.e., where you pass in an integer associated with a flag to an
nbconvert --execute
command and it builds up to and including that cell (nbconvert --execute --upto 5
would build cells 0 through 5). I don't think anything like this exists in the execute preprocessor today, but this doesn't seem too unreasonable of a feature to implement on the nbconvert side.The text was updated successfully, but these errors were encountered: