On 07/02/2012 10:54 PM, Olemis Lang wrote:
On 7/2/12, Gary Martin <[email protected]> wrote:
Anyway, as a fundamental part of a release is that it consists of the
necessary source to build the project, we need to make sure that our
installer is fit for the task of installing in that form, or, at least,
we give adequate instructions for how the project is built without using
the simple installer. Either way, changes to the installer should be
expected.
About this I wanted to suggest you to take a look at Trac's Makefile .
That approach seems to be connsistent with Trac develeopment workflow
and afaics might help to build packages for specific platforms and
environments (e.g. Linux dpkg , rpm ... , Windows msi , exe ...
database PostgreSQL , SQLite , ... and so on ) . Maybe it'd be nice to
add new Bloodhound-specific targets in there e.g. bloodhound_configure
bloodhound_install , ...
Well, we can already create binary and source distributions with
distutils. It might be nice to have a buildout recipe for installation
as well for an alternative installation and setup.
The pip install route still seems like a nice way to go but, with these
comments in mind, I have been experimenting with removing the automation
of the pip installs. With the requirements files we can continue to
encourage users to do their own pip installs with, or without,
virtualenv. In fact this might solve some problems on OS X where I seem
to remember issues with requiring XCode for virtualenv.
Anyway, there is no particular requirement for binary distributions to
be made available though we could consider whether this would be good
for future releases.
Any advice would be
great. It will probably help for us to have a set of standard tickets
that we can use to track our progress that can be replicated for future
releases.
... and if release process (... or part of it ...) can be automated
with Jenkins or Hudson or ... that may be a good starting point .
Yes, I am sure that we will be able to streamline the process in some way.
Cheers,
Gary
