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
Making ipynb support truly agnostics in agreement with Jupyter raise... #1774
Conversation
Note to myself... I have to make dicts for each kernel so they have the correct |
@@ -213,6 +213,14 @@ class CommandNewPost(Command): | |||
'bbcode, html, textile, txt2tags', | |||
}, | |||
{ | |||
'name': 'kernel', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to add a new option that will not apply to most compilers?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes... we need to specify the kernel to build the correct notebook template with the correct kernel specification... if not... the notebook is no validated ok and will fail...
I am open to ideas about how to deal with this that, as you said, is not available for other compilers...
One option would be probably make it only available with ipynb (warn and exit if you try to use it with other compilers... but maybe they are other options...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should totally fail when used with other compilers. And it should say in the help that it's only important for jupyter, something like
'help': 'Kernel to use for jupyter posts, irrelevant for all other formats' or somesuch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My idea would be to make it -f ipynb@python
— this will also be extensible in the future when we have other compilers with multiple formats (or -f pandoc@markdown
, for example)
If we do add this parameter, it must also be added in new_page.py
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My idea would be to make it -f ipynb@python
This is interesting... I will explore this possibility... we can probably provide the more popular formats: ipynb@python2
, ipynb@python3
, ipynb@julia
, ipynb@r
and leave the others kernels as a plugable thing (I mean not in core... there are more than 30 kernel... we can not support all of them in core).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much work is needed to support a kernel, exactly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an ipynb
with a different kernel spec... the thing about supporting more than the 4 main ones is that we need to explore how each of the other ~30 kernels specify their kernelspec and be awared of any change in the future...
…. Also create a clean notebook with agnostic properties (openable by any kernel).
…g things, but still WIP.
@ralsina @Kwpolska this is still WIP, but I am stuck in something and it is late... probably I am missing something obvious but I can not figured out.
The issue is that when I run It just takes the parent method... not adding anything... ideas welcomed. After that I just need to add the pyhon3, julia and R kernel metadata and it will be ready for review again... |
@@ -0,0 +1,10 @@ | |||
[Core] | |||
Name = ipynb_python2 | |||
Module = ipynb/ipynb_python2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That’s probably not the correct way to write that.
You must probably return I would personally prefer a sleeker implementation that would set |
OK, I will try it...
Sound interesting...
Can you elaborate you idea here a little bit more? |
|
Passing the parameter as part of the metadata here: https://github.com/getnikola/nikola/blob/master/nikola/plugins/command/new_post.py#L382?
OK |
Your idea for 2. makes sense, but we should do it if and only if the compiler has an |
…and init to go one level up with the ipynb plugin.
Did not work... but forget about that... I just following the last plan. |
…metadata according to the kernel name (ipynb.py). Also understand the compiler@subcompiler notation and sent the kernel name using the metadata (new_post.py).
Build failure due to setup.py still including ipynb as a package. Please fix that. (Also, we should switch to an automated package finder) |
Opps, I forgot that one... I will fix it now... |
Just set it to setuptools.find_packages() and it should work (adjust the Chris Warrick https://chriswarrick.com
|
let's try it... |
There is some error in appveyor... but I don't know if it is related with the |
It looks like we made it install our test suite in site-packages… I’ll fix Chris Warrick https://chriswarrick.com
|
'nikola.plugins.task.sitemap', | ||
'nikola.plugins.template', | ||
], | ||
packages=find_packages(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
packages=find_packages(exclude=('tests',)),
Also, in the future, please work on a branch in getnikola/nikola (not your own fork) so we can collaborate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, in the future, please work on a branch in getnikola/nikola (not your own fork) so we can collaborate.
Yes, I will take into account next time... make easier to collaborate, I agree...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, closing this one and opening a new PR in the getnikola/nikola becuase probably there are other things to fix...
WIP, but essentially let you use Jupyter (the IPython evolution) generating an ipynb with configurable language agnostic kernel and also populating the notebook metadata in a nikola namespace, so we now have support for
onefile
andtwofiles
(splitted meta). In this way, since the read_metadata is implemented, then we don't have to populate the metadata manually (or with jsextension)... all is more easy now just from the command line ;-)I have to test some things because it is too late now... I will probably complete it tomorrow, but should be enough completed for first review...