Fixed packaging and installation issues.

[jezdez]

This requires to use the official jupyter CLI tool to enable the extension after pip-installing it instead of using a custom solution.

It enables the option to install from whl files and fixes a threadsafety issue with the Tornado handler.

---

This change is

[jezdez]

@mreid-moz r? Let me know if you want to chat a bit about the changes I've made to this. Next is trying this version of the extension on a.t.m.o

[mreid-moz]

Looks good to me!

[vitillo]

@jezdez one of the original design decisions was that the package could be installed with pip without any extra steps. Unless there is a strong reason not to, I would love for the extension to be installed with a single command like as shown here. Could you please comment on that?

[jezdez]

@vitillo That's an understandable goal and I agree this would be preferable. I looked through a few bigger Jupyter extensions though and read the official Jupyter docs for distributing extensions as Python packages and came to the conclusion that separating the installation step from setting Jupyter config variables is the current and future best practice despite the fact that some extensions (notably those that have a history going back to the IPython community) haven't made the jump to it. I admit the community of extensions seem to be in the process to figure out more complicated configuration steps, as indicated by the relative simplicity of the activation steps. That isn't a problem for either this extension nor for jupyter-notebook-gist.

To summarize the reasons that made me separate the steps:

• setup.py based installation procedures such as the one used by the IPython-notebook-extensions only work when pip runs "install" procedures, which is a big Python anti-pattern that the Python community moves away from
• because of that the new official binary distribution format by Python ("wheel" files) doesn't run setup.py files during installation at all (it's a dumb zip format with ready metadata) which makes setup.py based configuration procedures effectively deprecated
• Jupyter extensions need to be installer agnostic to the lower maintenance friction with other means of installing Python packages e.g. via Anaconda's package management solution Conda
• big extensions have made or are currently planning to make the jump to "clean" Python package management configuration setups in favor of Jupyter's nbextension and serverextension commands
• there is tooling in the broader Jupyter community that offers easy starting points for new extensions
• using the new "clean" packaging patterns allows clean and automatic uninstallation

[vitillo]

@jezdez That makes sense, thanks for the awesome description of the rationale!

[jezdez]

@vitillo Thanks man, I'll keep an eye on the progress of the community a bit as well.