Comments (46)
Planned for the next release...
from rise.
* [ ] version number has to be standard, 3.x will be problematic, let's make it real and maybe turn into 0.3 and redo the previous releases as 0.1 and 0.2 (yes I know... it was a mistake trying to use 1.x, 2.x, etc)
from rise.
Sheepishly, I must admit I did a bunch of cowboy stuff without doing incremental commits and changing too many names: it's kind of broken, but parts of it might be salveagable.
I kind of like what @takluyver did with cite2c. Frankly, I didn't even know load_extensions
was a thing: seems pretty clean. At any rate, it should be one-liner require
-able, even if config of certain things was still possible.
To reduce the focus on fiddling with configuration files, I think any slideshow customizations (transition
, etc.) could move into notebook metadata... here's the thing I've been hacking on:
While I started building it against IPython to learn about actions, perhaps live_reveal
would be a more fulfilling place to put it, as a lot of the options don't make any sense unless you can actually see it working... of course, nbconvert
would have to know about it for it to be worth anything... but that's a good thing to shoot for!
Version: what's wrong with 3.x
? As IP 3 is imminent and reveal 3 is already out, it seems kind of appropriate.
Interested to see where this all goes!
from rise.
I have, for now, completely bypassed packaging systems in the cite2c install script, though that may have to change to handle the server side extension I've added recently. The load_extensions thing is nice because the install script can enable the new extension, but you can't do that as part of conda packaging or pip installation from wheels, because those can only place new files on the filesystem. There may be less need for this if @juhasch's config extension.
Version: If you've already done 1.x and 2.x releases, it seems like a bad idea to go back and call the next version 0.3. You'd have to rewrite history to number the old versions, and you're bound to miss something, and it would cause problems for everyone with the code already installed, or a clone of the repo, or whatever. Absent some really exceptionally good reason, I'd keep version numbers rolling forwards, even if I thought the numbering scheme was wrong.
from rise.
Screenshot.
Me. Just. Wow. O_O.
from rise.
wow, yes, I hadn't even paid attention to that. Are all of the second row slideshow related, or are they various different extensions? Maybe we should consider an API to add icon+text buttons, because I wouldn't want to bet on what any of those added buttons do.
from rise.
Maybe we should consider an API to add icon+text buttons
Because you think it's not already taken care of ?
Action = handler + icon + text + name
Toolbar = list of action.
Sprinkle with IPython magic and most things should work.
The only thing that I'm starting to consider is statefull action on/off (for now)
Of course some things above require custom code for dropdown :-)
from rise.
Because you think it's not already taken care of ?
Action = handler + icon + text + name
But I think the text is help text, not something to put on a button. It would also be part of the toolbar API whether to display a button as icon, text or icon+text.
Sprinkle with IPython magic and most things should work.
โจ โจ โจ ๐
from rise.
Yeah, yeah, I think we probably want the menu to use actions before that, and add requested features one at a time.
from rise.
add requested features one at a time
Heresy! ;-)
from rise.
- Developper add feature feature,
- Developper remove feature
- Developper release software to user.
- User destroy Developper,
- User add feature
Idea for the rest ?
from rise.
Are all of the second row slideshow related, or are they various different extensions?
Yes: those are all slideshow-level metadata. The other option would be to have a big modal where all of this was defined, and only a single button.
I'd like a well-thought-out icon/text/icon+text mode of the toolbars as well, eventually.
The only thing that I'm starting to consider is statefull action on/off (for now)
Yes, please!
from rise.
A lot of activity here... nice... some of my answers
Sheepishly, I must admit I did a bunch of cowboy stuff without doing incremental commits and changing too many names: it's kind of broken, but parts of it might be salveagable.
NICE, I will take a deeper look on the weekend
I kind of like what @takluyver did with cite2c. Frankly, I didn't even know load_extensions was a thing: seems pretty clean. At any rate, it should be one-liner require-able, even if config of certain things was still possible.
Yep, I agree...
To reduce the focus on fiddling with configuration files, I think any slideshow customizations (transition, etc.) could move into notebook metadata...
Yes, I thought about that in the past, the thing is find a way to make without messing the user with a high complex UI...
here's the thing I've been hacking on: While I started building it against IPython to learn about actions, perhaps live_reveal would be a more fulfilling place to put it, as a lot of the options don't make any sense unless you can actually see it working... of course, nbconvert would have to know about it for it to be worth anything... but that's a good thing to shoot for!
Yep
Version: what's wrong with 3.x? As IP 3 is imminent and reveal 3 is already out, it seems kind of appropriate.
Yeah, it can be...
There may be less need for this if @juhasch's config extension.
Yep, that's is very interesting... I think a lot of us want to see it merged in Jupyter soon...
I'd keep version numbers rolling forwards, even if I thought the numbering scheme was wrong.
OK, both convinced me... let's keep it in the current way...
But I think the text is help text, not something to put on a button. It would also be part of the toolbar API whether to display a button as icon, text or icon+text.
Yeah, I would love to have text on the button...
Yes: those are all slideshow-level metadata. The other option would be to have a big modal where all of this was defined, and only a single button.
I agree, that would be awesome...
from rise.
I understand from the check-list at the top that it doesn't work on Windows yet. Am I right?
Thanks
from rise.
I think it should. Try it and let us know what happens!
from rise.
Windows 7, 64bit, Anaconda - conda with Python 3, IPython 3.0 (just updated) and I get this:
C:\Users\franz\Documents\IPython Notebooks\RISE-master> python setup.py
Traceback (most recent call last):
File "setup.py", line 48, in
main()
File "setup.py", line 43, in main
install(use_symlink=args.develop, profile=args.profile,
AttributeError: 'Namespace' object has no attribute 'develop'
from rise.
I think you need to run python setup.py install
.
from rise.
You are right! Doing that it worked like a charm!
(I didn't know it... my apologies)
On Mon, Mar 2, 2015 at 10:41 PM, Thomas Kluyver [email protected]
wrote:
I think you need to run python setup.py install.
โ
Reply to this email directly or view it on GitHub
#52 (comment).
Francisco J. Navarro-Brull
from rise.
That's OK. I'm not quite sure why it works like that, because there's nothing you can put after it except install
. Maybe @damianavila is leaving room for future expansion.
from rise.
Maybe @damianavila is leaving room for future expansion.
In fact, this part was contributed from a user... probably something like python setup.py install
and python setup.py develop
would be nice to have, and the --[options]
for profile
, and eventually other options...
from rise.
As a windows report, python setup.py install --develop
does not work:
C:\Users\vdbosscj\Scipy\RISE>python setup.py install --develop
symlink C:\Users\vdbosscj\.ipython\nbextensions\livereveal -> C:\Users\vdbosscj\
Scipy\RISE\livereveal
Traceback (most recent call last):
File "setup.py", line 47, in <module>
main()
File "setup.py", line 43, in main
enable=(not args.no_enable))
File "setup.py", line 13, in install
overwrite=use_symlink, user=True)
File "C:\Anaconda\lib\site-packages\IPython\html\nbextensions.py", line 227, i
n install_nbextension
os.symlink(path, full_dest)
AttributeError: 'module' object has no attribute 'symlink'
But python setup.py install
does. And for the rest this seems to work fine on windows.
from rise.
Yes, it is a know issue about the "symlink" in windowa... not sure if there is a simple solution, I did not have touched win for years... @takluyver any idea about win support in the install_nbextension
?
from rise.
Ah, yes, the issue is here: ipython/ipython#6239
from rise.
No, I think --develop
probably has to be unsupported on Windows.
If you use Python 3 and you have a special permission bit set, creating symlinks normally will work, but that permission bit is off by default, so it's generally easiest to assume that you can't create symlinks on Windows.
There is something called 'NTFS juction points' which works like symlinks for directories, but I don't know of any Python programs that use those.
from rise.
No, I think --develop probably has to be unsupported on Windows.
Fine with me... you always can re-install... not as nice, but just a command to trigger... thanks for the additional info @takluyver
from rise.
This still isn't pip installable, even from master.zip
. Perhaps using jupyter-pip would smooth it out? then eventually a pypi release...
from rise.
The way things are moving with Python packaging (i.e. towards wheels), jupyter-pip is either going to break, or is going to increasingly need to circumvent the systems it. Looking at the code, I suspect it may already fail with pip 7. I don't think that's a good way to do things.
We're still trying to work out what extension packaging and distribution should look like. But one thing I think we're mostly agreed on is that installing and enabling an extension are not the same thing - though I see a place for a UI like Firefox's extension manager that installs and enables an extension with one click.
from rise.
I agree with @takluyver, I would not use jupyter-pip to do this... and, in fact, I am not sure we have to do a python package to install this... still thinking on it... why? Right now, we have a pure JS/CSS extension which only uses python to install/activate the thing... but, in the future, I would like to make all the component/objects "draggable" and persist that info in some way (so people can actually create your slides and "design" it on the fly)... maybe sending that info to the notebook server and writing it to a file (it could be other way, ideas? we should probably start another thread for that discussion). In that case it makes sense to have a python-based installation...
But well... maybe we can try a traditional setup.py approach, a conda one and maybe a npm one?
This + the bookmarlet gives the user a lot of options to try...
About the extension manager, we should be compatible with that when "that" happen...
from rise.
jupyter-pip works great at this particular moment... but not with wheels, indeed. The point here is that a) RISE isn't packaged and b) can't be installed with pip, 7 or otherwise, and jupyter-pip would solve that immediately.
RISE is (really) a pure js (and css... and fonts... and images...) nbextension, and having even rudimentary support for an existing package manager would nail this use case admirably, preventing us from re-inventing front-end asset management: see typescript, tsd
, ๐ข. Here's a tractably simple implementation of bower in python....
- not async (uses requests)
- doesn't resolve dependencies
- doesn't implement the turing-complete version grammar
...but could be advanced into something useful.
from rise.
Is there already a (meta-)thread for the long-con of front-end packaging someplace?
from rise.
We could use flit from @takluyver as well...
Did not tried yet but provides wheels support... @takluyver comments?
Is there already a (meta-)thread for the long-con of front-end packaging someplace?
I don't remember if there is one... or just some discussions on the meetings...
from rise.
We could use flit from @takluyver as well...
If there was an entry_point for nbextensions, flit would be a good match, as I assume it handles those! But wheels vs bdist, like bower vs npm, give you no opportunity to run scripts after install.
I would like to make all the component/objects "draggable" and persist that info
Let's not do anything that breaks nbviewer :) What I mean is, markdown is the "presentation" cell type, so we should try to work within that. But departing from markdown would carry a cost: with nb-inkscapelayers, I'm doing some terrible tricks with SVG that could be applied here:
"cells": [
{
"cell_type": "markdown",
"source": ["![](data:image/svg+xml;base64,a bunch of stuff)"],
"metadata": {
"rise": {"use_wysiwyg": true}
}
]
Get or make a suitable editor that can modify in-memory SVG, serialize it back out to that img tag, and the rendered view would be, no-fooling, what everyone else would see, and be editable. But it would be an image, no links, no interactivity.
For the actual editor, there is the creaky, but still alive svg-edit. I've looked at a few others, but they most are experimental or unsatisfying in some way.
A code cell with hacked output SVG or HTML would work :shivers:. But it might keep some semblance of searchability, which the base64 trick fails. But there would be many perils.
from rise.
If you want to make it installable with pip, you can use flit, but flit only makes wheels, and the tricks jupyter-pip does don't work with wheels. That's not just a bug with jupyter-pip: by design, wheels don't run code from the package at install time, so j-p can never work with wheels.
I'm inclined to agree with @damianavila that for things like RISE that don't involve any Python code, it would be rather bizarre to package them as Python modules. We have thought of using entry points, but it seems backwards to tie JS+HTML extensions to Python packaging, especially since it's not a packaging system that wins many awards.
(flit does handle entry points, btw :-) )
It would be fairly easy for us to design an extension packaging system for things like RISE. The tricky part is what we do for extensions that require a combination of server+frontend parts (e.g. cite2c), or kernel+frontend parts (e.g. any custom widgets). Do we try to have one packaging mechanism that works for all the different cases? Or do we carve them up somehow and only try to solve the easier cases? But this would be annoying if you started with a pure frontend extension and then needed to add a server part (as cite2c did), as you'd have to stop using the 'pure extension' packaging mechanism.
I can't immediately think of any single thread for this - it's one of those topics that has come up from time to time in different venues. We discussed it quite a bit at our last in-person dev meeting in Berkeley. There are notes from that, but we didn't record it.
from rise.
I can't immediately think of any single thread for this -
So, google group thread? Issue on jupyter/jupyter? (I|J)PEP?
from rise.
So, google group thread? Issue on jupyter/jupyter? (I|J)PEP?
Probably a thread at the jupyter mailing list is a good place...
even rudimentary support for an existing package manager would nail this use case admirably
As for now, in the case of RISE, I understand @bollwyvl position about making it installable, and we probably need to be pragmatic and come up with something... I am thinking into make a conda package, for sure, because of the agnostic nature of conda... and probably use flit because if you installed jupyter, you probably have pip there (or conda, which falls in the previous point)... thoughts?
from rise.
Probably a thread at the jupyter mailing list is a good place...
Will do!
I am thinking into make a conda package
Hooray conda. Will it enable it?
and probably use flit because if you installed jupyter
Unless we succeed in getting stuff into distros :) Still will have to manually install it... which is why I like the "hack" of jp's cmdclass
...
If manual enabling is okay, still another option is publishing a zip of just the livereveal folder to gh-pages: one could then use:
ipython install-nbextension https://damianavila.github.io/RISE/livereveal.zip
from rise.
Conda can install it (putting it into {prefix}/share/jupyter/nbextensions
) should work, but it can't enable it: conda packages are similar to eggs in that respect, they are just a collection of files that get unpacked to the right location.
ipython install-nbextension
(becoming jupyter nbextension install
) also doesn't enable it. Although in that case it technically could, we've stuck to the principle that installing and enabling should be two separate steps.
Maybe what we should be adding in the short term is a command-line interface to enable an nbextension? That way, although it would be two steps, we could easily give them to people together, e.g.:
conda install -c damianavila rise
jupyter nbextension enable livereveal/main # This bit doesn't exist yet
from rise.
Conda can install it (putting it into {prefix}/share/jupyter/nbextensions) should work, but it can't enable it: conda packages are similar to eggs in that respect, they are just a collection of files that get unpacked to the right location.
I think this is not entirely true... IIRC, you can add a post-script to your conda recipe to potentially enable things... let me find some link... ok, here: http://conda.pydata.org/docs/building/build-scripts.html
Maybe what we should be adding in the short term is a command-line interface to enable an nbextension?
Sound interesting (although as I said before, this should be solved with a post script in conda).
from rise.
In my conda nbextensions package I use a script to install files and also change the configuration. It should be even easier using the JSON instead of the PY configuration.
from rise.
Oh, neat. Then it should be possible to package frontend extensions as plain conda packages and enable them on install. And if I add an nbextension enable
command, it will be even easier.
from rise.
from rise.
Great, so... probably the summary:
- (canocanical) Make a conda package with enable on install (one step procedure) and publish to anaconda.org
- (secondary) Make a flit-based package so people can get it on pypi too (two steps procedure: install and then user dependent enable it from the CL)
- (devs) Install from repo with setup.py
How does sound?
from rise.
Sounds great. it will be even better to have "nbextension enable". The
issue over on the list has morphed into something far more terrifying, but
exciting!
On 08:18, Mon, Jul 20, 2015 Damiรกn Avila [email protected] wrote:
Great, so... probably the summary:
- (canocanical) Make a conda package with enable on install (one step
procedure) and publish to anaconda.org- (secondary) Make a flit-based package so people can get it on pypi
too (two steps procedure: install and then user dependent enable it from
the CL)- (devs) Install from repo with setup.py
How does sound?
โ
Reply to this email directly or view it on GitHub
#52 (comment).
from rise.
The issue over on the list has morphed into something far more terrifying, but
exciting!
Yep, really exciting, I agree...
from rise.
Am I right in assuming this has not been addressed yet?
from rise.
Dear god in heaven, THANK YOU! For real. This is great news!
from rise.
Related Issues (20)
- Weird layout when commands output large amounts of text HOT 6
- The slide does not adjust the height of a cell. Rather, it cuts down the view without enabling the scroll bar. HOT 3
- Vertical scrollbar not exported to HTML HOT 4
- Is it possible to remove left padding from code output cells? HOT 6
- RISE and Jupyterhub 3.x HOT 1
- Conda installation fails HOT 5
- Create a jupyter-slides (name to be discussed ;-) organization to house several Jupyter slideshows projects HOT 7
- Theme text color gets overwritten
- Missing example: header-footer.ipynb HOT 1
- Cannot autolaunch slideshow in Google Cloud Platform (GCP)
- Expand output cells to use available vertical space HOT 5
- Possible duplicate: Is there a way to edit settings for individual cells/slides, rather than for the entire notebook? HOT 2
- Lost custom css style when downloading as reveal.js slides html HOT 1
- Does this module allow interactive blocks? HOT 1
- RISE not showing because install uses notebook version 7 HOT 5
- RISE is obsolete and this should be made clear in the doc - redirect to jupyterlab-rise HOT 1
- RISE & Jupyter Notebook 7 HOT 1
- link to the documntation in read me file is broken
- Scrolling not activated "on the fly" when executing cell with an output making the slide longer.
- Searching for a workaround : is it possible to make scrollbar systematically present even on slides too small for it to have a use ? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rise.