Ship unminified js

[minrk]

For packaging.

closes #1265

Includes unminified single-file versions of prettify, jQuery-1.7.1, and jquery/jquery-ui@ba8f147

These files are totally unused.

[minrk]

js is also moved to top-level dir so it will only be included in sdists, not installs.

[takluyver]

What's the status with the different types of download we offer? I seem to remember that we already have a 'complete' tarball including doc sources, and a smaller tarball so pip install ipython is faster. We should make sure that people using pip or easy_install aren't waiting for an unused copy of jquery to download each time.

[minrk]

I think we just have one sdist, which no longer has the built docs, and would have this js. I don't think there are any tarballs with the docs other than downloading a snapshot of the ipython-doc repo.

[minrk]

If we want it to only be in the repo, and in no installs, then we can remove it from the manifest. In that case, the release tag on GitHub would have it, but sdists would not.

[takluyver]

I think I'd go with that path (removing it from the manifest), and point packagers to the tag-tarball on Github. For people regularly creating virtualenvs, I'd like to keep the download from pypi as small as possible.

[minrk]

@takluyver sounds good. For that matter, we could exclude the doc sources from the sdist, if we really wanted to keep it small.

[minrk]

removed from manifest.

[takluyver]

I'd lean that way, although we should think about it a bit, because there'll always be that time you want to refer to the docs somewhere without wifi, like on a plane.

• If you've got a git clone of the repository, you've got the doc sources handy anyway.
• On Ubuntu, ipython currently suggests ipython-doc, so it's not automatically pulled in. We could ask Julian to upgrade that to 'recommends', so it would be installed by default with ipython.
• I don't know if EPD/Python(x,y) ship docs - but presumably our sdist doesn't affect them.
• We could offer a docs download if you know you're going to be disconnected.

[fperez]

Let's consider what we do with docs separately... I've been thinking recently that, given the discussions we had at pydata indicating there will be no improvements to python docstrings forthcoming from python-dev ever, IPython should take the lead in offering documentation access to users.

Solid, easy to find help with good search and relevant examples is the one area where Matlab/Mathematica literally mop the floor with the python tools. It's not even funny how utterly pathetic our solutions are compared to what those environments offer on this front. But I think we now have in IPython enough machinery (in particular in the notebook) to tackle that problem, and to start thinking about how to offer better interactive access to help. Ultimately I'd like to do so for all the various projects, but we should obviously start by testing any ideas on IPython itself, before we suggest other projects adopt this.

[fperez]

Back to the topic of this PR, once we hear from @juliantaylor if it satisfies Debian's packaging policies in full, then I think we can merge. Thanks @minrk for taking care of this one!

[juliantaylor]

this should be enough to remove the need for repackaging (and the +dfsg) suffix. Thank you.
but why the toplevel directory? isn't the pip version generated from a sdist which can exclude it via the manifest?

I don't really want to bump the -docs to recommends, as a low bandwidth user I like my packages small and granular.
Its by far the largest package, not necessary for using the package and experienced users usually know that -doc's are not installed by default with the package.
For less experienced users there it is now quite prominently displayed in the software center as an addon.
(btw. a good screenshot for the software center should be added, http://screenshots.ubuntu.com/upload, the data is shared between multiple distributions)

[minrk]

but why the toplevel directory? isn't the pip version generated from a sdist which can exclude it via the manifest?

Honestly, I don't know where the best place is to put it. It didn't seem right that it was in the static dir, which looked too much to me like actually used code, and was available to notebook clients. And yes, it is easy to exclude or include it from anything, no matter where we put it.

Perhaps the most logical location is external/js, since these really are external dependencies (this PR now reflects this).

@juliantaylor thanks for your patience, and all your packaging help. Sorry for the bother.

[fperez]

+1 for external, just so it doesn't clutter the top level. Can you make that change before we merge it then?

[minrk]

already did :)

[minrk]

I clobbered the original commit, so it looks like I did it yesterday (git time machines ftw!)

[fperez]

sneaky; not fair to win an email race with a time machine ;)