Provide optional "dev" version augmentation

[arcivanov]

As described in #195 it seems to be desirable for PyB to increment generated versions of the artifacts.
It may also be desirable to do it for other projects as well.

The idea is as follows and is borrowed entirely from Maven -SNAPSHOT:

• User specifies version in build.py as ".dev0" (or "dev0", that will be normalized into a first version anyway)
• PyB uses that version completely unmodified everywhere exception in "install" and "upload" tasks.
• In all such cases the setup.py and other relevant distribution metadata is regenerated/patched with .dev0 turned into .devNm where N is a UTC microsecond timestamp, in the form of YYYYDDMMHHmmSSssssss.

[mriehl]

I think we should do this opt-in style because dev0 is a valid ending for versions (or is it not?)

• If the user sets the version to something that ends in devN, we replace the last N with the timestamp.
• If the user sets a dev version himself, we don't do anything (e.G. computes something from git)

So I would like to make it explicit that there is some patching going on and devN is more explicit imho

[arcivanov]

If the user sets a dev version himself, we don't do anything (e.G. computes something from git)

I'm confused by this statement. If "we don't do anything", who "computes something from git"?

[arcivanov]

otherwise 👍

[mriehl]

who "computes something from git"?

The user.
Say there's

version = '1.0.1.dev' + doMagicWithCurrentGitRef()

in build.py. Then we shouldn't patch it (even if doMagicWithCurrentGitRef resolves to 0).

[arcivanov]

I suppose then we can rewrite then this:

version = '1.0.1.dev'

or

version = '1.0.1.devN'

or these

version = '1.0.1dev'
version = '1.0.1devN'

respectively. I might actually lean towards .dev for rewriting with no suffix at all to allow a user to customize whatever number/suffix she wants.

Cool?

[mriehl]

Sounds good 😄

[arcivanov]

Ok .dev/dev it is.

[mriehl]

@arcivanov I just noticed that patching the version in install and upload would not be enough. Since travis takes care of upload itself (it would be complicated to set a password in the repo to use pyb upload) we probably need to do this when building the source dist (I don't know how travis uploads, maybe it just uploads the tar.gz, maybe it uses the setup.py to build a sdist and then upload..).

Unless there is a way to access the encrypted credentials (env variables or similar), then we could stick to pyb upload.

[arcivanov]

@mriehl Actually we can. We can have an encrypted .pypirc file and use that with pyb upload. It would not be complicated at all, I'm doing this on Jenkins internally (no encryption) into a pypiserver.

http://docs.travis-ci.com/user/encrypting-files/
https://docs.python.org/2/distutils/packageindex.html#pypirc