Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Install mathjax for offline use #714
Add simple function to
All you need to do to get offline mathjax is:
from IPython.external.mathjax import install_mathjax install_mathjax()
This could be located somewhere else, or also called from a magic, but external seemed the most logical place, since it is for bundling an external library.
I also reversed the priority of offline/cdn mathjax, so offline mathjax is preferred, since it is presumably less expensive to load. Of course, this is only true in the local network case, and a notebook server that's run from a real server would probably prefer to use the cdn. This is in a separate commit, so it's easy to rollback if we want to keep the CDN priority.
I actually was asking @ellisonbg about the same of switching priorities. On Friday for some odd reason the mathjax CDN was timing out on my firefox session (it seems to be some dd interaction with firebug, couldn't quite figure it out) and I had to do this switch locally just so I could keep working. But I'd like Brian to give us his take on it.
In terms of the other code, a couple of comments.
I'm not sure how much the latter is really needed, since you tend to only not have sudo on servers, which by definition need good net connectivity. This is mostly needed for laptops likely to be offline. I just want to float the thought before we finalize it and merge.
I think this makes perfect sense...but then where should we move the Qt import code to, since it doesn't qualify? And where should the mathjax install go? IPython.utils? IPython.frontend.html.notebook.util?
The ssh code was also put into external, with the argument that it is really a standalone tool, that could be brought into another package (specifically pyzmq). It can be moved to IPython.utils as well
It would be possible, as I think was discussed on IRC or Skype, to add some location in
It seems to me that IPython.utils is fine... I didn't realize that we had let other things slip into external. We should probably clean that up later on, though by now we'll have to be more careful and put in deprecation warnings, as someone is likely to have started using those locations.
As for the local install, we can leave that for a future pass, if you prefer. I don't have strong feelings about it.
If we want IPython.external to be something that distributors can easily ship without, then we should change all our conditional external imports, such that the try/except is in the actual import, rather then relying on IPython.external to do the logic:
try: import package except ImportError: from IPython.external import package
We frequently do just the external import, and let the