We need to support a multiplatform installation

[damianavila]

Some things to discuss/implement:

• remove dual installation... just let the python setup.py
• also support win
• support pip install
• conda package
• local and system wide installation
• how to deal with require in custom.js (I like the current solution although is hacky)

Other ideas welcome...

[damianavila]

* [ ] 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)

[bollwyvl]

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!

[takluyver]

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.

[Carreau]

Screenshot.

Me. Just. Wow. O_O.

[takluyver]

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.

[Carreau]

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 :-)

[takluyver]

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.

✨ ✨ ✨ 🐍

[Carreau]

Yeah, yeah, I think we probably want the menu to use actions before that, and add requested features one at a time.

[takluyver]

add requested features one at a time

Heresy! ;-)

[Carreau]

• Developper add feature feature,
• Developper remove feature
• Developper release software to user.
• User destroy Developper,
• User add feature

Idea for the rest ?

[bollwyvl]

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!

[damianavila]

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...

[franktoffel]

I understand from the check-list at the top that it doesn't work on Windows yet. Am I right?

Thanks

[takluyver]

I think it should. Try it and let us know what happens!

[franktoffel]

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'

[takluyver]

I think you need to run python setup.py install.

[franktoffel]

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

[takluyver]

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.

[damianavila]

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...

[jorisvandenbossche]

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.

[damianavila]

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?

[jorisvandenbossche]

Ah, yes, the issue is here: ipython/ipython#6239

[takluyver]

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.

[damianavila]

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

[bollwyvl]

This still isn't pip installable, even from master.zip. Perhaps using jupyter-pip would smooth it out? then eventually a pypi release...

[takluyver]

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.

[damianavila]

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...

[bollwyvl]

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.

[bollwyvl]

Is there already a (meta-)thread for the long-con of front-end packaging someplace?

[damianavila]

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...

[bollwyvl]

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.

[takluyver]

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.

[bollwyvl]

I can't immediately think of any single thread for this -

So, google group thread? Issue on jupyter/jupyter? (I|J)PEP?

[damianavila]

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?

[bollwyvl]

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

[takluyver]

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

[damianavila]

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).

[juhasch]

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.

[takluyver]

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.

[takluyver]

See jupyter/notebook#210

[damianavila]

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?

[bollwyvl]

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).

[damianavila]

The issue over on the list has morphed into something far more terrifying, but
exciting!

Yep, really exciting, I agree...

[xguse]

Am I right in assuming this has not been addressed yet?

[damianavila]

Planned for the next release...

[xguse]

Dear god in heaven, THANK YOU! For real. This is great news!