Travis deploy tags to PyPI

[GeorgianaElena]

This copies the release steps from other JupyterHub repos ✨

The only difference is that traefik-proxy uses versioneer that takes care of the project version and some steps are missing.

(@consideRatio I never worked with versioneer before, but from what I've read it seems that version is updated by it and we don't have to do anything. What do you think?)

[consideRatio]

LGTM overall. I don't have any experience with versioneer, but I've picked up on a not to positive sentiment about it.

I hope to avoid needing to learn about versioneer also, but will do if someone suggest I do because it makes sense to use it alongside no tool or bump2version that we have also used in other jupyterhub projects.

[consideRatio]

Ping @manics @betatim @choldgraf @willingc @minrk who have been active in discussion about this kind of tooling within jupyterhub/team-compass#213.

Me and @GeorgianaElena find ourselves having no experience using versioneer and involved in the maintenance of this repo, having a file named versioneer.py. In JupyterHub repos I've only seen bump2version and custom scripts so far.

This is the first JH repo with versioneer I've seen. My suggestion is that we remove it from this repo. Is that okay? I'm also fine not doing it, but it would be nice with a call on this.

[manics]

I've never used versioneer either

[manics]

https://github.com/warner/python-versioneer/blob/master/README.md
After a quick glance it sounds like it might be even easier to use than bumpversion, perhaps requiring just a git tag. If so I think we should investigate it further before removing it.

[manics]

Additional information, apparently versioneer may be unmaintained which would be a reason to remove it:

• Consider using setuptools-scm instead of versioneer pytroll/satpy#678
• Future plans for versioneer pydata/xarray#2853

[choldgraf]

I can't remember where but I believe that we've discussed versioneer before in another thread, and concluded that it was overkill. I'd be +1 on removing it from this repository now, and if folks want to re-consider using it across all the repositories, then we can open a team-compass issue about it

[consideRatio]

After looking in setup.py, _version.py, __init__.py, I've become very afriad of the complexity introduced by this system. I favor doing something very easy to understand without much complexity at all, like manually updating 1-2 files specified in the release instructions.

[minrk]

I would not change the use of versioneer here; that can be a separate discussion, with pros and cons, mostly summarized as:

• pro: creating releases is simpler because no files need to be edited (repo2docker's release process benefits greatly from this)
• pro: development versions report their exact commit automatically (minor benefit unless development-version use is common)
• con: installation from development versions other than the main git repo (git-archive, forks with out-of-date tags) works fine, but can report the wrong version (which may stop 'working fine' when dependencies enter into it)
• con (or pro): autogenerated files handle many cases and are thus more complex than manually edited files.

I favor doing something very easy to understand without much complexity at all, like manually updating 1-2 files specified in the release instructions.

I'm not sure if I would object to removing versioneer if a problem does indeed arise, but releasing a versioneer project is simpler and easier than releasing one that requires manual editing of one or more files because making the tag is the always the only step and requires no installation of additional tools (e.g. bump2version).

[GeorgianaElena]

I updated the PR with everyone's feedback. Hope I didn't miss anything :)

I will open a new issue to summarize our discussion here and keep it for future reference.
I believe we can go on with versioneer as it is and continue the talk about removing it if anything starts failing. What does everybody think?

[betatim]

We use versioneer in repo2docker and it works well. It is a long file but (and this is where it is better than all other things I've used) it just works. I've never needed to read the code and I don't know of a situation where repo2docker --version didn't print the correct thing. It works in the cases where people git clone or pip install https://github.com/org/repo/archive/master.zip or ...

To create a release the instructions are https://repo2docker.readthedocs.io/en/latest/contributing/tasks.html#creating-a-release There are three steps: git tag ..., git push ... and creating a release on GitHub.

[consideRatio]

After the commit suggestion i made is committed, I want to press merge! This looks very thorough to me!

[consideRatio]

Thanks @GeorgianaElena for thorough work with this PR and the patience with deliverations regarding tooling involved! ❤️ 🎉