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
Liquid tags #21
Liquid tags #21
Conversation
that looks great. However, I would love to have this not only bound to markdown, but also available for people using restructured text, do you think that would be useful? |
I agree that would be nice, but would basically require writing and testing an entirely new implementation. The current one is built on markdown preprocessors, and you'd have to do the equivalent with ReST preprocessors as well. I've never dug into ReST - do you know if it would be straightforward to do? |
When I attempted to used the Liquid tags notebook plugin from this pull request (21) with a very simple markdown post and IPython notebook, I get the following error upon running pelican:
If I comment out lines 144-145 of notebook.py and rerun pelican, everything is fine and the html post looks as expected. Thus, I believe the error is not valid. I have only briefly looked into debugging the issue and haven't yet figured out the problem. Here is some information about my setup:
Please let me know if I can provide further information or test something. |
That piece is a bit of an ugly hack -- once the nbconvert architecture is stabilized, we should be able to select cells within nbconvert, rather than slicing up the generated html. It would be better to try and fix this once the nbconvert refactor is finished. |
No problem. I knew what this code was doing and this is why I didn't spend tons of time debugging it since I could myself hack it and make things work. Given the situation with nbconvert, I figured you'd want to wait. At least it's documented now as having been an issue for the future. |
Hey, I'm quit interested in this plug in. Do I need to expect significant changes before this PR gets merged? |
Thanks for the contribution, Jake. To recap, here's where we are so far: @ametaireau said:
@jakevdp replied:
I agree reST support would be nice, but I suspect we should merge this in its current form for the following reasons:
Last but not least, even if we merge this plugin in its current form, anybody is of course free to pick this up again in the future to implement support for reST, Asciidoc, and other formats. Just my two cents. Any other thoughts? |
Actually, I'd like to first make sure the notebook piece works with the finished nbconvert refactor -- I haven't had a chance to do that piece yet. While we're at it, we may as well wait until nbconvert is merged into IPython for the 1.0 release, slated for July. |
Any update? |
Not yet - I'm still planning to wait for the IPython 1.0 release, otherwise we'll have to rewrite this code again in a month. |
Just so folks can keep up-to-date -- I've been working on getting the features into IPython 1.0 that will allow this PR to be finished, and finished well. IPython work here: |
@jakevdp Thanks for the info. Have been waiting patiently for all the necessary updates. Happy to give it a try when ready. |
@jakevdp thanks for the update. I'm eager to give it a try too. |
Awesome, we're almost there! |
help="last cell of notebook to be converted") | ||
|
||
def call(self, nb, resources): | ||
nbc = deepcopy(nb) |
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.
Will now take care of that for you :-)
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.
nb
and resources
are now guaranted to be deepcopied before beeing passed to the first transformer, so you shoudl be safe of not deepcopying it yourself if you are concern with performance.
For anyone curious, this currently does not work with the IPython release candidate (some things have been renamed). I'm working on remedying that. |
Turns out is was a simple name remapping. This should work with the IPython 1.0 release candidate available at this tag: https://github.com/ipython/ipython/tree/1.0.0a1 There are a few nbconvert bug fixes in the process of being backported from master for release. Again, we should wait until IPython 1.0 is final to merge, but I think this is pretty close! |
Fantastic, Jake. Excited for the release! |
Oups, sorry for the name conflict, I try to warn you when there are changes that might affect the plugin, but this one slipped through my fingers. |
- First, the plugin requires that the nbconvert package [1]_ to be in the | ||
python path. For example, in bash, this can be set via | ||
|
||
>$ export PYTHONPATH=/path/to/nbconvert/ |
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.
Think this needs updating since nbconvert is now in IPython.
We'll need to watch out for this change, though it's IPython 2.0: ipython/ipython#4044 |
We will probably also rename Exporter -> TemplateExporter as we will have one more base classe. |
# Below is the pelican plugin code. | ||
# | ||
SYNTAX = "{% notebook /path/to/notebook.ipynb [ cells[start:end] ] %}" | ||
FORMAT = re.compile(r"""^(\s+)?(?P<src>\S+)(\s+)?((cells\[)(?P<start>-?[0-9]*):(?P<end>-?[0-9]*)(\]))?(\s+)?$""") |
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'd be nice if this could handle spaces in the filename. Perhaps allowing people to specify the filename in quotes would disambiguate the situation?
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.
I agree that would be nice, but I think adding this sort of thing would overly-complicate an already extremely dense regular expression. Something like this would work:
FORMAT = re.compile(r"""^(\s+)?(?P<src>\"[^\"]*\"|\'[^\']*\'|\S+)(\s+)?((cells\[)(?P<start>-?[0-9]*):(?P<end>-?[0-9]*)(\]))?(\s+)?$""")
But then you end up with a string containing quotation marks if they're used, which adds further complicated post-processing. Additionally, a regular expression like this is extremely difficult to read, maintain, and understand, even if you're the person who wrote it!
The best option would be to write a simple modular parsing framework to express these things within the submodule, but I don't really have the bandwidth to take that on right now. Plus, who puts spaces in their filenames anymore? 😄
This looks cool - will you be adding {% for %} and {% if %}, and if so, can they wrap cells, i.e., can I put: +------------------------------+ and have it work as expected? Because I'd use that right away :-) |
@gvwilson - that's a bit beyond the scope of this. The liquid tags are within the pelican markdown file, not within the notebook itself, so I'm not sure how that would work in this context. |
@gvwilson this would go into nbconvert template/transformers, then in pelican you could do :
|
Aside from several feature requests which I likely won't get to, I think this is ready to merge. There's certainly going to be work in the future to make it compatible with IPython 2.0, and perhaps add a better parsing framework than the raw regular expressions I'm currently using. Also, adding RST support would be nice, if someone wants to take that on. None of those are blockers, though, and I'd like to finalize what we have. |
A user noted that if sphinx is not installed, then the IPython version check was giving a misleading message. I fixed that. |
What is the current status of this pull request? |
Ready for merge |
Thanks to Jake for all the hard work on this plugin, with due appreciation to others who assisted. |
Please,
Avoid publishing passive aggressive comments like that. It's not
helpful, to anyone.
It's sometimes hard for maintainers to find the time to work on all the
issues, especially when it comes to managing plugins and themes.
Pelican-plugins was at first thought as a way to catalog all the
plugins. If the project is maintained somewhere else it's a good news,
not a bad one :-)
Big up to anyone who helped on this. And please, avoid being aggressive
to people who commit their free time to open source projects.
Cheers,
Alex
…On 07/06/2018 19:40, Natalino Busa wrote:
... fast forward 5 years, still not merged, although it works perfectly.
Fortunately, this very useful and inspiring plugin is maintained on a
separate repository ...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#21 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAEGAY11_F5MpDHyR2Bdg3VkziYLj7vZks5t6WV8gaJpZM4AoLxr>.
|
Most users of the theme do not set any favicon. It results in useless HTTP requests Fix getpelican#21
This adds a set of extensions to use Liquid-style tags within markdown (similar to those provided by octopress). There are four tags included at this time, though the module is written to be easily extensible:
Insert images of a given size:
Insert HTML5/flash compatible videos:
Insert code from a file, with a title and link to download:
Insert an HTML-rendered ipython notebook:
Examples and details of how to use each are in the Readme file, and in the doc strings of each plugin.