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
autoexported notebooks: only export explicitly marked cells #3295
Comments
|
So how should a generic post-save hock look like? |
|
Ok, so something along this lines?
How would a plugin then register itself? |
I don't think the notebook manager is where these things will live. We are quickly moving to a model that supports multiple directories. In that context, each directory might want to have a different configuration of these types of hooks. However the notebook manager would be the same object for each directory. IOW, we won't instantiate a new notebook manager for each directory. This represents an entirely different type of configuration abstraction than we current have. We will need to think carefully about how to represent that well. But, these things are very much in flux and I think we just need to wait for some of this other work to land first. |
Ok, nothing to be done about this issue until that refactoring is done? If yes: when will this refactoring land in IPython? Other things:
|
@JanSchulz Regarding the injection part you can use the functions in IPython.core.display. |
I'm currently thinking about using the
An extension could then simple add a function to the hook via The So, before I start coding: would such a thing be considered for merging at all and before the refactoring mentioned above? |
So, the idea is implemented in https://github.com/JanSchulz/ipython/commits/define_hooks (last 4 commits). It still needs a --skript parameter to the notebook startup and the js part needs to be loaded via Unfortunately the %load_ext directly for both parts (hook and js) does not work: the ip object in the extension is a different one than the get_ipython() one in the filenbmanager :-( I'm not sure how to get an extension into the notebook application... |
And a cleaner implmentation, which uses the notebook metadata to define a postsavehook: Workflow:
To check which cells will be written to the .py file choose 'Cell Toolbar: auto export hin' and change the setting for each cell. |
My current thinking is to define a cell level magic
|
I'm not sure I understand what you meant by (transformed -> no magics...) No a cell magic does not have access to cell metadata, it is no possible as The save if no change would be too complicated for it's goal if it is just The cell "identifier" would be cell ID that we will tackle later. Le lundi 17 juin 2013, JanSchulz a écrit :
|
My usecase would be fixed by minrk/ipython_extensions/pull/11 This could also be included in ipython itself by adding this methods to IPython/core/magic/code.py (there is a |
I beg your pardon, but could you please explain how to get this done? I was looking for some way to supress some cells from the exported results but I didn't find a way to do this fastly. Thanks! |
I try to do my data munching and statistics in IPython notebooks. I start the notebook server with "--script" and my notebooks (up to now...) are mixing imports, functions and data munching (loading, apply the functions, save result). I tried to reuse parts of the notebook in other notebooks but run into two problem / annoyances:
So, it would be nice if the notebook could add metadata to a cell, which would basicly instruct the exporter to "export this cell" or "do not export this cell". This could then also show an error when a magi command is encountered in a "marked for export"-cell. Another idea would be to simple comment out any encountered magic command.
Additionally it would be nice if the notebook server could be instructed to a) export the notebook if such metadata is found, even if not run with "--script" and b) use a specified name for the python file.
The text was updated successfully, but these errors were encountered: