New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide optional "dev" version augmentation #209

Closed
arcivanov opened this Issue Sep 23, 2015 · 9 comments

Comments

Projects
None yet
2 participants
@arcivanov
Contributor

arcivanov commented Sep 23, 2015

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.

@arcivanov arcivanov added this to the v0.11.2 milestone Sep 23, 2015

@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Sep 23, 2015

Member

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

Member

mriehl commented Sep 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Sep 23, 2015

Contributor

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"?

Contributor

arcivanov commented Sep 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Sep 23, 2015

Contributor

otherwise 👍

Contributor

arcivanov commented Sep 23, 2015

otherwise 👍

@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Sep 23, 2015

Member

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).

Member

mriehl commented Sep 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Sep 23, 2015

Contributor

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?

Contributor

arcivanov commented Sep 23, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Sep 23, 2015

Member

Sounds good 😄

Member

mriehl commented Sep 23, 2015

Sounds good 😄

@arcivanov

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Sep 23, 2015

Contributor

Ok .dev/dev it is.

Contributor

arcivanov commented Sep 23, 2015

Ok .dev/dev it is.

mriehl added a commit that referenced this issue Sep 24, 2015

Set up travis for PyPI upload
Related to #195
This should upload every travis build from master (no PRs) to PyPI.
We're currently simply using the number of git commits since the repo
moved to git as a `dev` version suffix.
With #209 it will be possible to just set the version to `*.dev` for
upload.
@mriehl

This comment has been minimized.

Show comment
Hide comment
@mriehl

mriehl Sep 24, 2015

Member

@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.

Member

mriehl commented Sep 24, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@arcivanov

arcivanov Sep 24, 2015

Contributor

@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

Contributor

arcivanov commented Sep 24, 2015

@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

@mriehl mriehl modified the milestones: v0.11.3, v0.11.2 Oct 21, 2015

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Nov 11, 2015

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Nov 12, 2015

arcivanov added a commit to arcivanov/pybuilder that referenced this issue Nov 12, 2015

@arcivanov arcivanov closed this in #242 Nov 12, 2015

@arcivanov arcivanov removed the in progress label Nov 12, 2015

AlexeySanko pushed a commit to AlexeySanko/pybuilder.github.io that referenced this issue Oct 4, 2017

AlexeySanko
1) project attributes into build.py
2) project version with suffix '.dev' - pybuilder/pybuilder#209

AlexeySanko pushed a commit to AlexeySanko/pybuilder.github.io that referenced this issue Oct 4, 2017

AlexeySanko
1) project attributes into build.py
2) project version with suffix '.dev' - pybuilder/pybuilder#209

AlexeySanko pushed a commit to AlexeySanko/pybuilder.github.io that referenced this issue Oct 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment