Setting version from commandline or setup.cfg?
Hello, I'm trying to automate my release process from vcs - something like: run tests -> fetch current major, minor from branch (e.g. release_1.2) and revision from tag (e.g. v1.2.1) -> upload with current major, minor and revision +1 > tag with such current major, minor and incremented revision. I'd like to set my version from outside my setup.py file, either via setup.py or a commandline option - I don't want to execute code in my setup.py since this usually causes all sort of headaches with missing dependencies. Is there any proper way to do it? Might I break other things unexpectedly? -- Alan Franzoni -- contact me at public@[mysurname].eu
Op 11-01-11 12:51, Alan Franzoni schreef:
Hello, I'm trying to automate my release process from vcs - something like:
run tests -> fetch current major, minor from branch (e.g. release_1.2) and revision from tag (e.g. v1.2.1) -> upload with current major, minor and revision +1> tag with such current major, minor and incremented revision.
I'd like to set my version from outside my setup.py file, either via setup.py or a commandline option - I don't want to execute code in my setup.py since this usually causes all sort of headaches with missing dependencies.
Is there any proper way to do it? Might I break other things unexpectedly?
I suggest using a tool like: http://pypi.python.org/pypi/zest.releaser http://pypi.python.org/pypi/jarn.mkrelease http://pypi.python.org/pypi/collective.releaser Depending on which vcs you are using you may need some extra packages, see: http://pypi.python.org/pypi/zest.releaser/3.18#prepare-for-pypi-distribution When testing any of these tools you may want to create a local subversion/git/mercurial/whatever repository and create a small package there to test releasing it. -- Maurits van Rees Programmer at Zest Software http://zestsoftware.nl Personal website http://maurits.vanrees.org/
On Tue, Jan 11, 2011 at 2:41 PM, Maurits van Rees <m.van.rees@zestsoftware.nl> wrote:
Op 11-01-11 12:51, Alan Franzoni schreef:
Hello, I'm trying to automate my release process from vcs - something like:
run tests -> fetch current major, minor from branch (e.g. release_1.2) and revision from tag (e.g. v1.2.1) -> upload with current major, minor and revision +1> tag with such current major, minor and incremented revision.
I'd like to set my version from outside my setup.py file, either via setup.py or a commandline option - I don't want to execute code in my setup.py since this usually causes all sort of headaches with missing dependencies.
Is there any proper way to do it? Might I break other things unexpectedly?
I suggest using a tool like: http://pypi.python.org/pypi/zest.releaser
I have played a bit with zest.releaser, and while it seems interesting I'm not sure about some things, e.g.: I'd like to test my project *before* committing any version change or tagging anything. I'd like to pass a "candidate changeset" for a release; if all tests on such release succeed, I'd then like to tag the current changeset, upload everything to pypi, upgrade setup.py (or version.txt) with the next development version. zest.releaser offers setup.py entrypoint hooks, but maybe a buildout hook (run another part) would work better? Also, version.txt looks better than embedding the version in setup.py, but I'd like to follow even more a convention-over-configuration thing; I'd like release branches to be named something like release_1.2 release_1.3 and I'd really like to pull version numbers from the branch name and latest revision from the tag info - nor version.txt neither setup.py should be committed at any time - that's often an issue because when working with multiple branches, the forward merge of version changes often produces merge errors that must be corrected manually. Saving version info in metadata like branch names or tags is a better solution, I think. I'll try playing a bit with the zest.releaser source by the way, If I can reach a good result I'll let you know. -- Alan Franzoni -- contact me at public@[mysurname].eu
Op 16-01-11 14:32, Alan Franzoni schreef:
I have played a bit with zest.releaser, and while it seems interesting I'm not sure about some things, e.g.:
I'd like to test my project *before* committing any version change or tagging anything. I'd like to pass a "candidate changeset" for a release; if all tests on such release succeed, I'd then like to tag the current changeset, upload everything to pypi, upgrade setup.py (or version.txt) with the next development version. zest.releaser offers setup.py entrypoint hooks, but maybe a buildout hook (run another part) would work better?
I would say just run the tests manually first (possibly as simple as running bin/test if you have a good buildout configuration) and then use the fullrelease command from zest.releaser. If you are afraid that changing the version string and updating the changelog/history file might possibly break the tests you could first run the prerelease command to set the version and history, then run the tests, then run the release command to tag and push to pypi or somewhere else, then the postrelease command to update the version and changelog of your current branch/trunk checkout to a development version.
Also, version.txt looks better than embedding the version in setup.py,
For the record, having a version.txt is a convention from years ago when Zope/Plone products needed it, because python packages with a setup.py were not widely used within Zope at that time, possibly because they had not been invented yet. :-)
but I'd like to follow even more a convention-over-configuration thing; I'd like release branches to be named something like
release_1.2 release_1.3
and I'd really like to pull version numbers from the branch name and latest revision from the tag info - nor version.txt neither setup.py should be committed at any time - that's often an issue because when working with multiple branches, the forward merge of version changes often produces merge errors that must be corrected manually. Saving version info in metadata like branch names or tags is a better solution, I think.
When you upload your package to pypi.python.org setup.py needs to know what version it is. In other words: you need some way of having 'python setup.py --version' come up with the correct version. Yes, merging can produce conflicts, but if version conflicts in a changelog and a setup.py are your worst merge problems then you can count yourself blessed. :-)
I'll try playing a bit with the zest.releaser source by the way, If I can reach a good result I'll let you know.
Cool. I get the feeling you are trying to solve a problem that I don't have or that I do not consider a problem though, so don't get your hopes up too high that changes are accepted for a release. But the code is in the Plone collective, so feel free to make a branch there: https://svn.plone.org/svn/collective/zest.releaser/trunk Getting write access to the Plone collective should not be too difficult. Short instructions are here: http://dev.plone.org/collective Cheers, -- Maurits van Rees Programmer at Zest Software http://zestsoftware.nl Personal website http://maurits.vanrees.org/
On Sun, Jan 16, 2011 at 8:50 PM, Maurits van Rees <m.van.rees@zestsoftware.nl> wrote:
I would say just run the tests manually first (possibly as simple as running bin/test if you have a good buildout configuration) and then use the fullrelease command from zest.releaser.
Yup, I'm tinkering with something like that, and it seems fine in fact. I don't know why I thought it was harder.
and I'd really like to pull version numbers from the branch name and latest revision from the tag info - nor version.txt neither setup.py should be committed at any time - that's often an issue because when working with multiple branches, the forward merge of version changes often produces merge errors that must be corrected manually. Saving version info in metadata like branch names or tags is a better solution, I think.
When you upload your package to pypi.python.org setup.py needs to know what version it is. In other words: you need some way of having 'python setup.py --version' come up with the correct version.
I have noticed that, and it ultimately makes sense. Once it's a .tar.gz there's no VCS under it, it can't possibly know which version is around.
Yes, merging can produce conflicts, but if version conflicts in a changelog and a setup.py are your worst merge problems then you can count yourself blessed. :-)
Wherever there's unneeded manual work, there's something to fix. Such problems does not arise in Python projects, it's often very painful when developing Java with Maven as well; and can sometimes have hellish consequences. If after a long-and-painful merge anyone forgets to put the correct version number in the version file and then goes on by releasing it, stakes are high that problems will arise.
Cool. I get the feeling you are trying to solve a problem that I don't have or that I do not consider a problem though, so don't get your hopes up too high that changes are accepted for a release.
That's probable. In that case I won't modify the releaser, maybe I could start a totally different project, but I'd like to reuse what can be reused. -- Alan Franzoni -- contact me at public@[mysurname].eu
participants (2)
-
Alan Franzoni -
Maurits van Rees