p01.releaser 0.6.0

Release helper script which offers a simple release process

Summary

install

Download and unzip this package next to your other packages in your local svn folder structure. After that, install the p01.releaser package by running the following commands on linux:

python bootstrap.py

bin/buildout

windows:

python bootstrap.py

binbuildout.exe

release

You can use the release method with the following command for make a new or next release.

nix:

bin/release <package-name>

windows:

binrelease.exe <package-name>

With this command the release script will do the following for the package with the given name:

• check for pending local modification

• find existing versions

• get next version based on options (-n, –next-version)

• guess next version if nothing defined in options

• ask for confirm guessed version or set explicit/initial version

• ask for CHANGES.txt release text confirmation if already exist

• or offer inplace CHANGES.txt editing if empty confirmed

After this, the srcipt will start an automated build process and abort on any error. Note an error could end in partial commited svn data or a missing release file. But this should be simple to check and correct. The steps are:

• update version in CHANGES.txt if not already updated during editing

• update version in setup.py

• commit version change (local pkg dir)

• create release based on setup.py (local pkg dir)

• ensure tags folder if new package get release

• tag package (svn cp tags/pkgName/version)

• guess next release version

• add next version and unreleased marker in CHANGES.txt

• add next version including dev marker in setup.py

• commit setup.py and CHANGES.txt dev marker update

Now you are done and the release should be ready.

in short

In short, the releae script should normal only do the following steps:

• ask for new guessed version confirmation

• ask for CHANGES.txt confirmation or offer editing

and the release should just start.

credits

This package is a kind of simple version of keas.build for one package. The keas.build package offers support for build several release based on configuration files. This is usefull if you need to make several releases based on deifferent packages but not for release the package itself.

README

This package provides a release helper script which can get used for svn based repository development. The script will do all the steps which are required forrelease a package and add a dev marker if done. A new package release will get uploaded to the right pypi based on the package url. If authentication is required, the script will find them in your HOME/.pypirc configuration file. This means there is no configuration required if your package meta data is correct defined and your “python setup.py sdist upload” command works.

Requirement

Before using the script make sure the following requirements are fine:

- correct <HOME>/.pypirc setup

- pypi package server tweaks in setup.py (see Server Lock below)

- working "python setup.py sdist upload" command

- correct meta data (url, version) in <package>/setup.py

- existing CHANGES.txt file in your package

Setup

You can setup the p01.releaser as a buildout part using the offered entry_point. See setup.py. But I recommend not using the script as a buildout part in your package because it will include the part in your deployment.

The recommended way to use the script is to link the p01.releaser package as an svn external in your package <root> next to your other packages. It doesn’t matter which svn layout structure you are using. The release script will automaticaly detect the svn repository layout and find the relevant folders. With such a setup, you can go to the p01.releaser package and call the release command. Of corse, you have to run:

python bootstrap.py
bin/buildout

before you can use the method:

bin/release

The releaser script will find the correct package and tag folder based on your svn layout. See below for more information about the common svn repository layout structure.

Note

The release method will only release the package if something changed since the last release. The release method will also not start the release process if there is pending (not commited) code in your package. And the release method supports you by adding comments to the CHANGES.txt.

SVN

We support 2 kind of svn layout. The first layout is the default layout used for independent python libraries. Each package provdies own branches, tags and trunk folders:

- <root> (svn layout detection rule: can't use trunk as name)
  |
  |- p01.releaser (cwd location)
  |  |
  |   - bin
  |     |
  |      - releaser.py (releaser.exe)
  |
  |- package1
  |  |
  |   - branches
  |  |
  |   - tags
  |  |  |
  |  |   - 0.5.0 (version)
  |  |
  |  |- trunk
  |     |
  |      - src ...
  |
   - package1
     |
      - branches
     |
      - tags
     |  |
     |   - 0.5.0 (version)
     |
     |- trunk
        |
         - src ...

The second svn layout is used for frameworks or other group of packages. Each package is located in the same trunk folder and they share branches and tags folders. This layout provides the option to simply tag all packages in one step:

- <root>
  |
   - branches
  |
   - tags
  |  |
  |   - package1
  |     |
  |      - 0.5.0 (version)
  |
   - trunk
     |
     |- p01.releaser (cwd location)
     |  |
     |   - bin
     |     |
     |      - releaser.py (releaser.exe)
     |
     |- package1
     |  |
     |   - src ..
     |
      - package2
        |
         - src ..

Server Lock

The p01.releaser script will upload a relase to the pypi server found based on the <HOME>/.pypirc information. This should prevent that a release accidently get uploaded to the official public pypi server. But remember, the package meta data in <package>/setup.py must proide te correct url. And if you start the release process by hand with the command “python.setup.py sdist upload” you will release to the public pypi server which is probably not what you want.

Our solution which we use for private packages is the following. We use a mypypi server and a locker.py script in each of our private packages. This script provides the following content:

import sys
import os.path
from ConfigParser import ConfigParser


#---[ repository locking ]-----------------------------------------------------

def getRepository(name):
    """Return repository server defined in  .pypirc file"""
    server = None
    # find repository in .pypirc file
    rc = os.path.join(os.path.expanduser('~'), '.pypirc')
    if os.path.exists(rc):
        config = ConfigParser()
        config.read(rc)
        if 'distutils' in config.sections():
            # let's get the list of servers
            index_servers = config.get('distutils', 'index-servers')
            _servers = [s.strip() for s in index_servers.split('\n')
                        if s.strip() != '']
            for srv in _servers:
                if srv == name:
                    repos = config.get(srv, 'repository')
                    print "Found repository %s for %s in '%s'" % (repos,name,rc)
                    server = repos
                    break
    if not server:
        print "No repository for %s found in '%s'" % (name, rc)
        sys.exit(1)
    else:
        return server

def lockRelease(name):
    """Lock repository if we use the register or upload command"""

    COMMANDS_WATCHED = ('register', 'upload')
    changed = False
    server = None

    for command in COMMANDS_WATCHED:
        if command in sys.argv:
            # now get the server from pypirc
            if server is None:
                server = getRepository(name)
            # found one command, check for -r or --repository
            commandpos = sys.argv.index(command)
            i = commandpos+1
            repo = None
            while i<len(sys.argv) and sys.argv[i].startswith('-'):
                # check all following options (not commands)
                if (sys.argv[i] == '-r') or (sys.argv[i] == '--repository'):
                    #next one is the repository itself
                    try:
                        repo = sys.argv[i+1]
                        if repo.lower() != server.lower():
                            print "You tried to %s to %s, while this package "\
                                   "is locked to %s" % (command, repo, server)
                            sys.exit(1)
                        else:
                            #repo OK
                            pass
                    except IndexError:
                        #end of args
                        pass
                i += 1

            if repo is None:
                #no repo found for the command
                print "Adding repository %s to the command %s" % (
                    server, command )
                sys.argv[commandpos+1:commandpos+1] = ['-r', server]
                changed = True

    if changed:
        print "Final command: %s" % (' '.join(sys.argv))

With this locker.py script, you can simply lock the release to an own pypi server with the following command in your setup.py file:

import locker
locker.lockRelease("projekt01")

The single lockRelease method argument must be an existing index-servers name defined in your <HOME>/.pypirc file. The .pypirc file could look like:

[distutils]
index-servers = pypi
                mypypi

[pypi]
repository: http://pypi.python.org/pypi
username:<username>
password:<password>

[mypypi]
repository: http://pypi.domain.tld
username:<username>
password:<password>

This locker.py script concept is a seatbelt an prevents any release file upload to a wrong pypi server with or without the p01.releaser scipt. Remember the releaser script will find it’s correct server without this script. But it’s allwayys a good idea to backup the concept if you have important libraries.

Issues

Just like to remember that distutils is broken because of a bad re pattern. It is not possible to include buildout.cfg or other files starting with build on windows. This is only relevant if you need to include additional package data with include_package_data=True. After patching your pyhton installation it should be fine to include a MANIFST.in file with:

include buildout.cfg

see:

http://bugs.python.org/issue6884

CHANGES

0.6.0 (2012-11-16)

• added comment about distutils issue

• added strict connection error handling

• implemented checking externals

• implemented better edit option

• improve tests, fix test condition

• fix changed marker

• replace CHANGES.txt wrapper class ChangeDoc with a simpler implementation and API

0.5.4 (2011-08-27)

• new version did not get added to CAHNGES.txt before release

0.5.3 (2011-08-27)

• bugfix broken back to dev step

0.5.2 (2011-08-27)

• improve version/date parsing. Something like this window.open(‘’) was parsed as version headline

• skip inline editing, just open the CHANGES.txt file and abort. I will probably bring back the CHANGES.txt fiel editing back if I’ll find a way to open the file in an editor an block the subprocess till the editor will get closed. This is not so simple because opening a file in an already open editor will not block a subprocess.call

0.5.1 (2011-08-25)

• added missing register argument in setup.py call. Seems that the pypi index needs this option or a package will not show up in th index

0.5.0 (2011-08-25)

• initial release done with p01.releaser