Add automatic deployment to pypi when tag is pushed #833
Conversation
`setuptools_scm` works that it provides a version even when you build it locally and it generates the version into a file at the time of packaging, which means there is no run-time-dependenty on the `setuptools_scm` package later on (and also no dependency on git, or internet access). This makes a simplified release flow, because it enables you to just add a tag and CI pushes the end package to the PyPi for end users to use. Option is also to provide development packages, etc. (just the matter of how far we want to take it). There is no required tag name, although we should follow some of the standard formats of Major.minor.patch or whatever it is preferred.
…dentially commit it
There was a problem hiding this comment.
I'm sort of leaning towards the implementation in #822 instead of setuptools_scm as bumpversion seems ot be more flexible. We've been wanting to automate release with Travis though, I'm definitely 👍 on this part of the change.
We can probably treat Travis tag releases and the underlying version update mechanism as separate work, they are independent pieces. Perhaps back out the setuptools_scm bits here and we can focus on this first? Version change automation is not super high priority or blocking issue atm, but making it easier for core theme team to cut releases is one of our priorities.
|
OK, I will prepare travis only change for releasing on tag. I am against effort of keeping bumpversion (commited) and tags in sync, but that's just lazy me. |
setuptools_scmworks that it provides a version even when you build itlocally and it generates the version into a file at the time of
packaging, which means there is no run-time-dependenty on the
setuptools_scmpackage later on (and also no dependency on git, orinternet access). This makes a simplified release flow, because it
enables you to just add a tag and CI pushes the end package to the PyPi
for end users to use.
Option is also to provide development packages, etc. (just the matter of
how far we want to take it). There is no required tag name, although we
should follow some of the standard formats of Major.minor.patch or
whatever it is preferred.
Before merging we should fill in the secure password (hashed with original repo) and username of the maintainer for pypi. This is added as allow edits from maintainers so that they can add all the details before merging.
closes #812
if we decide to go this way.