Package: collective.releaser
Report any bug or feature requests to :http://trac.ingeniweb.comContentsWhat is collective.releaser ?How to install collective.releaser ?How to use collective.releaser ?Setting up your environementCreating the project structureCreating egg-based packageReleasing eggsReleasing the projectUpgrading an existing buildout0.7.1 (2010-12-08)0.7.0 (2010-09-30)0.6.6 (2009-09-17)0.6.5 (2009-08-31)0.6.4 (2009-08-18)0.6.3 (2009-08-18)0.6.2 (2008-04-09)0.6.1 (2008-07-16)0.6.0 (2008-07-16)0.5.2 (2008-06-19)0.5.1 (2008-06-10)0.5.0 (2008-05-21)0.4.1 (2008-04-29)0.3.6 (2008-04-29)0.3.5 (2008-04-22)0.3.4 (2008-04-17)0.3.3 (2008-04-17)0.3.2 (2008-04-17)0.3.00.2.90.2.80.2.70.2.60.2.50.2.40.2.30.2.20.2.10.2.00.1.90.1.80.1.70.1.60.1.50.1.40.1.30.1.20.1d0.1c0.1b0.1What is collective.releaser ?collective.releaser provides command line utilities to make it easier to release
and deploy zc.buildout/subversion based projects.It provides:new setuptools commandsrelease: used to release an egg-based packagebuild_mo: used to search and compile .po fileconsole scriptsproject_release: used to release a buildout based projectproject_deploy: used to deploy a buildout based projectproject_copy_eggs: used to collect all eggs used in a projectproject_md5: used to compute the MD5 hash of a buildout projectpackage_svn_prepare: to restructure a new created package to be svn readya hook to be able to launch actions when a package is released,
with a default one that sends an email on each release.a paste template to create a project structure, calledreleaser_project.How to install collective.releaser ?To installcollective.releaser, you just need to run easy_install:$ easy_install collective.releaseror you can launch its setup if you have downloaded it:$ python setup.py installHow to use collective.releaser ?To work with collective.releaser, let’s do a small tutorial on how to create
a buildbout-based project. This is done in a few steps:setting up your environmentcreating the project structurecreating egg-based packagesreleasing eggsreleasing the buildoutupgrading an existing buildoutSetting up your environementThe first thing to do to work smoothly with zc.buildout is to set up a
few things on your environment that apply globally to any Buildout-based
applications.Put two files in your home directory:HOME/.buildout/.httpauth: this file will contain the authentication
information if the system tries to reach a http(s) ressource which is
password protected (like a svn server or a private web site).
It is a text file where each line is: realm,url,user,passwordFor example:trac,https://svn.ingeniweb.com,user,password
pypi,http://products.ingeniweb.com,user,passwordThis is used bylovely.buildouthttp.HOME/.buildout/default.cfg: This file set some defaults values, so
Buildout can cache and spare downloaded eggs.For example:[buildout]
download-cache = /home/tarek/.buildout/downloads
eggs-directory = /home/tarek/.buildout/eggsNext, you need to make sure you can release your eggs to several
targets, because you may want some private eggs not to be published on
PyPI. At this time, the only software that provides the same
web services than PyPI is Plone Software Center >= 1.5.To make it possible to handle several PyPI-like servers,
we need to install a small add-on, calledcollective.dist:$ easy_install collective.distThis will allow you to define several servers in your ~/.pypirc file.
For instance if you are working with a private PyPI-like server you can
define it like this in HOME/.pypirc[distutils]
index-servers =
    pypi
    ingeniweb-public

[pypi]
username:ingeniweb
password:secret

[ingeniweb-public]
repository:http://products.ingeniweb.com/catalog
username:ingeniweb
password:secretLast, you need to define the release strategy configuration, that
will define for each target server the list of packages that must be released
there (regular expressions) and the command sequence that is used
with setup.py. Here’s a default example, that can be added in your.pypircas well, by completing the sections withrelease-commandandrelease-packagesvariables:...

[ingeniweb-public]
...
release-command = mregister sdist build_mo bdist_egg mupload
release-packages =
    ^iw\..*

[pypi]
...
release-command = mregister sdist build_mo bdist_egg mupload
release-packages =
    ^plone\..*
    ^collective\..*This will push all eggs that starts withplone.orcollective.to PyPI and all eggs that starts withiw.to ingeniweb-public.
The command used to push the packages are defined bycommand.Creating the project structureEvery project must be structured the same way:$ paster create -t releaser_project my_projectThis will ask you for a few values:project_name: the name of the projectproject_repo: the root of the subversion repositorysome more values that can be left to default.This will generate a set of folders inmy_project:$ ls my_project
./buildout
./bundles
./docs
./packages
./releasesEach folder has a role:buildout: contains the buildout configuration filesbundles: contains the bundle used to work in develop modedocs: contains the documentation about the projectpackages: contains the egg-based package(s)releases: contains the releases of the buildoutThis structure must be commited in subversion:$ svn import my_project http://some.svn/my_project -m "initial commit"You will then be able to work in your buildout.Creating egg-based packageFrom there you can add some packages into the project, by putting them
in thepackagesfolder, by using any template available in ZopeSkel.Be carefull though, you must use a trunk/tags/branches structure in
packages for each project.$ cd my_projet/packages
$ paster create -t plone plone.example
$ package_svn_prepare plone.exampleThe last command just does the following:$ mv plone.example plone.example_md5_of_plone.example
$ mkdir plone.example
$ mkdir plone.example/tags plone.example/branches
$ mv plone.example_md5_of_plone.example plone.example/trunk
$ svn add plone.example
$ svn ci -m "initial import of  plone.example"Do not use trunk as a package name with paster, as this will generate
bad metadata in the package.A special section can be added intosetup.cfg, in order
to send a mail everytime the package is released:[mail_hook]
hook = collective.releaser:mail
from = support@ingeniweb.com
emails =
     trac@lists.ingeniweb.comIf your system does not have a SMTP server, you will need to add
the name of a SMTP server, and its port in your .pypirc file,
in amail_hooksection:[mail_hook]
host = smtp.neuf.fr
port = 25From there you can bind the package to your buildout, with a develop
variable, in yourmy_project/buildout folder:[buildout]
...
develop=
    .../packages/monprojet.reports/trunkThebundlefolder can also be used to set svn:externals to make it
simpler to work in the buildout.Releasing eggsReleasing eggs is done by callingreleasefrom a package:$ python setup.py release
running release
This package is version 0.1.2
Do you want to run tests before releasing ? [y/N]: N
Do you want to create the release ? If no, you will just be able to deploy again the current release [y/N]: Y
Enter a version [0.1.2]: 0.1.2
Commiting changes...
Creating branches...
...This will take care of:upgrading the setup.py versioncreating a branch and a tag in svnpushing the package to the various PyPI-like serverssending a mail with the changes, if the mail_hook section was provided in setup.cfgIf you want to release a package from a non-svn folder then use this command to disable specific svn hooks:$ python setup.py release --pre-hook --post-hookYou can also use some parameters to avoid command line prompt:$ python setup.py release -a --version=0.1.3Releasing the projectReleasing the project consists of callingproject_releasethenproject_deploy.project_releasewill just create a new branch in subversion:$ cd my_project/buildout
$ project_release --no-archive --version=0.1This will copymy_project/buildouttomy_project/releases/0.1in
subversion. You can then work in this release, to pinpoint the versions
in your buildout. A good practice is to create a dedicated cfg file
for deployment.The next step is to generate a tarball withproject_deploy:$ cd /tmp
$ svn co http://somesvn/my_projet/releases/0.1 my_project
$ cd my_project
$ project_deploy prod.cfgThis will build a tarball in/tmpusing VirtualEnv, and set everything up
so the buildout can be reinstalled offline anywhere with this archive.The resulting release can be installed with two lines:$ python boostrap.py
$ bin/buildoutUpgrading an existing buildoutTo upgrade an existing buildout, you can use theproject_releasecommand.
It will create a tarball with all eggs needed to run the project and the
.cfg files.Run it in your buildout, by pointing the .cfg and by providing a name of
the archive:$ cd my_project/buildout
$ project_release --version=0.2This will release all develop eggs found indev.cfg. If yourdev.cfglook like:[buildout]
parts = eggs
develop =
  ../my.package
  ../my.other

[eggs]
recipe = zc.recipe.egg
eggs =
  my.package
  my.otherThenmy.packageandmy.otherwill be released and then added to an archive
with all .cfg files.If you have a static version in yourprod.cfg:[buildout]
parts = eggs
versions = versions

[versions]
my.package = 0.1

[eggs]
recipe = zc.recipe.egg
eggs =
  my.package
  my.otherThen onlymy.otherwill be released but both added to the archive.The default config file of the archive (eg:buildout.cfg) will look like
this:[buildout]
extends = prod.cfg
versions = versions

[versions]
my.package=0.1
my.other=0.2So you can just run./bin/buildouton your production server to use the
correct packages versions.0.7.1 (2010-12-08)Fixed issue with mingw32 not working inside the virtualenv,
by making sure we copy the distutils.cfg file.
[deo]0.7.0 (2010-09-30)Added some fixes to make (most) tests pass on Windows.
[dreamcatcher]Fixed issue with broken target file on project_deploy.
[dreamcatcher]Changed to only upgrade setuptools/zc.buildout if requested.
[deo]Added a dependency on virtualenv instead of shipping with an
outdated version which potentially can damage your development
environment.
[deo]0.6.6 (2009-09-17)Made sure to resolve the filename to use an absolute path.
[gawel]Made sure that our package is in sys.path before releasing.
[gawel]Fixed ReST formatting issue.
[gawel]0.6.5 (2009-08-31)Fixed NameError introduced here (https://dev.plone.org/collective/changeset/85145/collective.releaser/branches/refactor/collective/releaser/project.py)
[glenfant]Made tests smile
[glenfant]0.6.4 (2009-08-18)More docs and sphinxifying docs.
[gawel]0.6.3 (2009-08-18)project_release improvement (seehttp://www.gawel.org/weblog/en/2009/05/collective.releaser_rocks) [gawel]removed the long_description checker (belongs to collective.dist now)
[tarek]0.6.2 (2008-04-09)make sure the bootstrap.py works offline [tarek]fixed build_mo command for Django eggs [b_mathieu]0.6.1 (2008-07-16)adding a buildbot folder, with a pre-generated
collective.buildbot environment [tarek]prefacing all svn commit messages [tarek]better tarball naming [tarek]introduced glob-style option to be able to do
glob-style patterns
[tarek]removed branch creation
[tarek]0.6.0 (2008-07-16)fixedproject_deployso
it supports non buildout.cfg buildouts
Thanks to Hans-Peter Locher for feedback
[tarek]using Popen to read metadata [tarek]0.5.2 (2008-06-19)now checking the long_description field to make sure
it is reST compliant [tarek]backported Python 2.5 tarfile module [tarek]fixed #66 [tarek]0.5.1 (2008-06-10)emptied parts section in the template/
[tarek]os.rename -> shutil.move
[tarek]added paster() in testing to ease tests
[tarek]Fix empty or missing parts under windows when the recipe use subversion
[encolpe]0.5.0 (2008-05-21)moved to collective
[tarek]added package_svn_prepare command to restructure a new created package with
trunk, tags and branches then add it to the current working copy and ci it
to svn as ‘initial import’ if the current directory is a working copy.
[mustapha]0.4.1 (2008-04-29)nowreleasecan be driven from .pypirc as well
[tarek]We are not removing setup.cfg in releases anymore,
because it can have elements. We just remove the dev tag.
[tarek]0.3.6 (2008-04-29)wrote the documentation
[tarek]added the iw_plone_project template
[tarek]release command take care of version.txt if any
[gawel]add release hook
[gawel]0.3.5 (2008-04-22)added the project_eggs command
[tarek]now adding a MD5 file in the tarball released
[tarek]added project_md5
[tarek]0.3.4 (2008-04-17)added project_copy_eggs
[tarek]0.3.3 (2008-04-17)Excluding Scripts, Lib and downloads/dist
[tarek]0.3.2 (2008-04-17)protecting  shutil.rmtree call
[tarek]make the python prompt generation smarter
[tarek]remove stale bytecode by default. (This mean –keepbytecode has to be used
in order for the test to work)
[tarek]0.3.0fixed os.curdir misusagefixed build_mo (indent error)fixed over simple build_mo tests by adding garbage files0.2.9fixed a missing import0.2.8removed parts, bin, lib and other folders
from the release. We will have a special
mode later to provide them when a pre-built
is needed.fixed the project_diff target location0.2.7now has a config file to target the pypi serversproject_release was not working with svn:// repositories0.2.6copying the libpython*.a file into buildout’s libs folder, so virtualenv
works with MinGW under windows.added a version.txt file in the releases.0.2.5making sure we get virtualenv python2.4.*cleaned up tarball contentmaking project_deploy work within the same folder0.2.4removed extra questions in project_releasefixed release namefixed checkouts0.2.3added project_diff0.2.2make sure virtualenv (some version under win32) work with Scripts/python0.2.1make sure virtualenv work with ‘python’ or ‘python2.4’the auto mode for package release is not launching the tests anymorefixed msgfmt type comparison0.2.0making sure the right cfg file is called with project_deploy0.1.9added ‘build_mo’ command for setuptoolsfix project_release relative pathsexplicitely uses ingeniweb-private to release
package0.1.8fix CR/LF0.1.7fix multiple upload0.1.6removing eggchecker0.1.5make sure we don’t release by accident on unwanted server0.1.4fixed the callerusing virtualenv to isolate egg on project_deploy step0.1.3added command line options0.1.2making sure download-cache is presentadded a snapshot file that is commited in the buildout
that is beeing releasednow tarball can contain only diffs from snapshotsadded iw.dist support0.1drelease step is not mandatory anymore0.1cremoved eggchecker dependency0.1brenamed release module to packet moduleimplemented a project release-r0.1initial version created by IngeniSkel