Start using vagrant-spk. Install everything with apt and pip.

[dwrensha]

This started as me wanting to use OpenCV with IPython. Curious about what it would take to add the cv2 package to the Sandstorm app, I tried to get the jparyani/sandstorm branch running. I noticed that it's possible to install Jupyter/IPython entirely through apt-get and pip, and we don't actually need to modify any upstream code to get the app to run. Any Sandstorm-specific customization that we need can be done through custom.js. I'm using custom.js here to prevent notebooks from opening in new windows.

This new packaging abandons the "one notebook per grain" model, but until we've made a lot more progress on the powerbox, that model is more trouble that it's worth, I think. It's quite natural to have "one project per grain", and that opens the door to uploading notebooks, as in https://github.com/jparyani/ipython/issues/2, and to uploading data files, e.g. images to be used with OpenCV.

Adding new packages, as requested in https://github.com/jparyani/ipython/issues/5, should be a simple matter of editing a line in setup.sh.

I've moved the notebook directory from /var to /var/home, so that random stuff like a font cache does not clutter the file tree view displayed to the user.

After these changes, the app should act very much like https://try.jupyter.org/.

[dwrensha]

Test spk hosted here: https://oasis.sandstorm.io/shared/H6PAamRf5harFvUtGTAfCDtP0K13DXf2FhteCq7WuFW Note that this spk does use the actual published app ID, so it will try to upgrade IPython grains that you already have. That should work, but please be careful.

[dwrensha]

To understand this change, looking directly at https://github.com/dwrensha/ipython/tree/sandstorm is probably easier than looking at a diff.

[dwrensha]

@jparyani: you expressed some concern about switching from "one notebook per grain" to "one project per grain". Here is an example project that I think could make a lot of sense to host on a Sandstorm grain: https://github.com/jvns/forestspy . In the "one notebook per grain" model, how would we handle the adults.data and forestspy.py files?

[jparyani]

Typically, I've had cells at the top and/or bottom of my notebooks along the lines of:

import os, sys

workspace_path = "/var/workspace"
if not os.path.exists(workspace_path):
    os.makedirs(workspace_path)
sys.path.append(workspace_path)

with open(os.path.join(workspace_path, 'forests.py'), 'w') as f:
  f.write('print "test"')

import forests

Obviously this is pretty confusing to the average user, and if we're going to ask people to do it this way, we need some good docs showing it. This is obviously not ideal, and potentially very confusing/space wasting for binary data. I'm just not sure it's worth abandoning the one notebook per grain model right before we're so close to supporting powerbox fully.

[dwrensha]

Typically, I've had cells at the top and/or bottom of my notebooks along the lines of: ...

What if I want to view or edit forests.py after uploading it? How would this work for importing, say, a 5MB JPEG file?

we're so close to supporting powerbox fully

What will importing these auxiliary files look like when we have powerbox support? Maybe you upload the image to a FileDrop grain, and then the IPython grain makes a powerbox request for it when it wants to read it? That sounds like more trouble than it needs to be.

[jparyani]

I'm sorry I let this languish so long. I'm fine with changing the behavior of the IPython spk to now start users on a file list. It's also going to make it easier to support Python2/Python3 alongside one another.