Refactor CI Support

[mindw]

• Added appveyor support (testing on Windows) https://ci.appveyor.com/project/mindw/pyjwt
• Refactored tox.ini to eliminate duplication using recent tox features.
• Refactor setup.py
• Convert jwt script to entrypoint - make it usable on Windows.
• Refactor setup.py to eliminate customizations.

[coveralls]

Coverage decreased (-10.96%) to 89.04% when pulling 6ece16d on mindw:xy into a125433 on jpadilla:master.

[mark-adams]

Thanks for the PR. Looks like things aren't quite right yet... The coverage numbers seem off a bit

[mindw]

Yes it is expected. The jwt script was moved to reside inside the source tree but no tests for it exist. Only two configurations retained they original name so they reflect a 10% drop in coverage.

It was always there, undetected.

[mark-adams]

Yea, we either need to write tests for that thing or get rid of it as discussed in #130 to get rid of this coverage issue.

[mindw]

What about the contrib stuff? Isn't it redundant given the use of cryptography?

[coveralls]

Coverage remained the same at 100.0% when pulling 06b7414 on mindw:xy into a125433 on jpadilla:master.

[mark-adams]

The contrib stuff is basically the old pre-cryptography code that we reintroduced a few months back. Some users who were using PyJWT reported they were unable to use RSA on Google App Engine because it doesn't allow for compiling modules with C extensions. As a result, cryptography isn't an option so we brought the code back so they could fallback on PyCrypto if needed in GAE and similar scenarios.

[mindw]

Ok. Please note that you need to setup and account on appveyor for its badge.

Any other comments for this pull request?

[jpadilla]

@mindw any specific reason for these changes?

[mark-adams]

I agree, why are we manually reading this in instead of doing a simple import like we were previously?

[mindw]

The import happens before any of the project dependencies are installed and it will fail in case they are missing. A better variant og the above is to have a _version.py file in the project with the version and 'exec' it.

[mindw]

I'm looking into using setuptools_scm instead which will eliminate the version bookkeeping alltogher,

[jpadilla]

Oh I see when it might actually fail. Let's do this instead.

def get_version(package):
    """
    Return package version as listed in `__version__` in `init.py`.
    """
    init_py = open(os.path.join(package, '__init__.py')).read()
    return re.search("__version__ = ['\"]([^'\"]+)['\"]", init_py).group(1)

version = get_version('jwt')

That's what we use here.

[mindw]

You can see the discussion here for recommendations:
http://stackoverflow.com/questions/2058802/how-can-i-get-the-version-defined-in-setup-py-setuptools-in-my-package

Please review my latest version which eliminates 'version' extraction completely while providing automatic version management.

[coveralls]

Coverage remained the same at 100.0% when pulling 8ace48a on mindw:xy into a125433 on jpadilla:master.

[coveralls]

Coverage remained the same at 100.0% when pulling d2b3f24 on mindw:xy into a125433 on jpadilla:master.

[jpadilla]

@mindw I think next steps here should be simplifying this PR down to the changes for appveyor, travis, and tox. I'm mostly 👎 on setuptools-scm as I don't think that's currently an issue. I'd like a separate PR for actually removing bin/jwt so we can actually track that and document the change correctly. Thanks again for your work on this!

@mark-adams I'm I missing something else?

[mindw]

@mark-adams My apologies for the delayed answer.

The issue at had is how to share the version number between the package itself and the metadata. Currently there are two possibilities:

1. put the version in the setup.py (metadata) - As implemented by this pull request.
2. put the version in the package.

The reasons why options 1 is better are:

1. A single place for the version - eliminate duplication and reduces chances for errors (version = latest tag).
2. Provides a distinct PEP440 compliant version for every unofficial build.
3. Eliminate redundant code from setup.py (DRY - don't repeat yourself).
4. Shorten release procedure (tag, sdist, upload).

The perceived negatives are the the setup_requires dependencies. Which is irrelevant when providing wheels.

@jpadilla advocates 2. Which does not have the above additional advantages but is a solution to the problem.
In addition, The recommended implementation differs from the one suggested by @jpadilla. The recommended way is to place a file inside the package (_version.py) containing the version into the package and place the following into setup.py:

_locals = {}
with open('jwt/_version.py') as fp:
    exec(fp.read(), None, _locals)
__version__ = _locals['__version__']

Simple and compatible with any pep 440.

A good discussion can be found here.

[mindw]

@jpadilla It is unlikely I can spare the time and effort to split this small pull into even smaller parts. If it will help I can do some minor fixups.
Should the decision would be for options 2 I'll do the extra work for it.

It was never my intention for this to consume so much time.

[mark-adams]

No worries. I pulled the approved commits into a separate PR so we can get them merged in. (#157). Thanks for contributing!

Feel free to submit additional PRs (for #130 or anything else)!