Flit packaging

[takluyver]

@jquast flit is my packaging tool to build wheels without involving setuptools. With this branch I can build a wheel by running flit wheel.

We can use this:

1. Standalone, by getting rid of setup.py and MANIFEST.in. This means that future releases would only have wheels on PyPI, not sdist tarballs. I'm already doing this for a number of my other projects - pip has been able to install wheels for about 2½ years - but it may surprise some people.
2. In parallel, using flit to build wheels and setup.py for sdists. There's a risk of duplicated information getting out of date, but the main thing we update is the version number, and flit takes that from __version__, which we need to update anyway.
3. I have a shim called flituptools so setup.py can use the flit information. But that would limit sdists to use with Python 3.

[jquast]

Fine with me, go ahead.

[takluyver]

OK, going with option 1 (wheels only) for now. We can consider option 2 or 3 later if there are too many complaints.

[jquast]

python setup.py sdist bdist_wheel upload uploads both a source distribution and wheel package, this is the method I use in https://pypi.python.org/pypi/blessed with only some minor changes, just a setup.cfg file. Can we do that?

[takluyver]

I avoid using setuptools if I possibly can, because it has messed up my import path order so often. I detest that package.

[jquast]

After some experience accommodating the use of flit in our build environment, I feel we've created another difficult barrier to development entry for contributors. Its become difficult for me, anyway. https://github.com/pexpect/pexpect/blob/master/tools/teamcity-runtests.sh has been broken, and I've having a difficult time repairing it with missing setup.py file. I aimed to replace this testing process with tox, pexpect/pexpect#60 but now I have additional issue pypa/flit#75

Just expressing this is maintenance cost, and I'm not sure what the win is.

[takluyver]

Sorry, I didn't realise you were testing against development versions of ptyprocess in that script as well. I think it's simplest for ptyprocess to revert this for now. I'll open a PR to do that.

For the record, there are various things I like about using flit, like reducing the duplication of the version number without ugly hacks, eliminating the need for package_data and MANIFEST.in, and the ability to easily refer to a separate file for the long description. It's a collection of small wins rather than one big one - although for me, not being setuptools is a huge win all by itself.