by gldnspud on April 21, 2009
Just a short post, but I'm excited about something that has been in the works for a little while now. My company, ElevenCraft, is now the owner of Schevo, the object-relational database I've been working on for several years with Patrick O'Brien of Orbtech, L.L.C. and PyCrust fame.
Additionally, we're relicensing Schevo under the MIT license to make things less complicated for using Schevo with any other software project, open source or commercial.
Since Patrick is taking an indefinite vacation from the world of software development to enjoy other exciting opportunities he has brewing, I'd like to take a moment to thank him publicly for all of the work that he did to help make Schevo one of the most elegant pieces of software I've ever laid eyes upon.
He was also instrumental in my progression from Python journeyman to master, and I am forever thankful for his fussiness about code style. Paying attention to those kinds of details really does make a difference!
Pat, I wish you the best in your new ventures, and I thank you for your generosity with regard to handing over the reins to the project. You are always welcome back to the world of Python and Schevo!
by gldnspud on April 14, 2009
Update: I no longer use this recipe, as it turned out to be an elaborate workaround for Paver 1.0 ignoring setup.cfg and distutils.cfg when using a Paver-based setup.py file. I'm now using a patch that allows Paver to honor such configuration files.
I've been using Paver, a tool to help manage various bits of administrivia surrounding Python projects, with Schevo for several months now. Now that Paver has a 1.0 release, I'm also using it to help streamline such tasks for the commercial software I'm helping develop.
One of the patterns I'm used to is attaching dev to the end of versions, to help differentiate between development versions and release versions.
I wanted to go further than this, also attaching the name of the current git branch name to the version number. That practice is useful when you use branching to manage feature development and bug fixes.
Here's the pattern I settled on. The relevant parts of pavement.py look like this:
from paver.easy import *
from paver.setuputils import setup
VERSION = '1.2.3'
DEVELOPMENT = True
# Use branch name if git information is available; otherwise, use
# version number from setup_meta.
if DEVELOPMENT:
try:
git_head_path = path('.git/HEAD')
contents = git_head_path.open('rU').readline().strip()
name, value = contents.split()
BRANCH = value.split('/')[-1]
if BRANCH != 'master':
VERSION += '-' + BRANCH
except:
pass
VERSION += '-dev'
setup(
name='MyProject',
version=VERSION,
...
)When generating releases, set DEVELOPMENT to False, commit that change, tag and release, then change the value back to True and commit again.
