I confess I haven't had a chance to familiarize myself with Buildout,
and will do so soon.
Thanks for the tip, Jim.
On 16.04.2014 18:57, Jim Fulton wrote:
On Wed, Apr 16, 2014 at 12:18 PM, Tin Tvrtković <[email protected]> wrote:
Hello packaging community,
I'm investigating ways of setting up Python projects at my workplace. We're
predominantly a Java shop, but we might be dipping our toes in Python waters
(finally!) due to a fortuitous project and my multi-year insistence, so I'm
contemplating how to set up our Python build system to minimize workflow
differences for other developers (well, and myself).
I've actually written uš a lengthy description of Maven and why we use it
but I'll spare you for now. :) To keep the story short, I'm interested in
options for setting up a multi-module Python project. By 'multi-module' I
don't mean a single setuptools-based project with several .py files inside,
but a way of triggering a complex build process with a single command that
would build all sub-modules (essentially sub-projects) and produce a number
of end artifacts - just like Maven. Imagine a repository containing 30
separate Django apps, packaged independently, 10 utility libraries, 10
Django projects combining those app, and 10 RPM building projects for
packaging it all up for deployment.
As far as I know, just using setuptools isn't adequate for a workflow like
this - setuptools deals with the build process (testing, packaging, etc) of
a single project only. Solutions that come to mind are: a hierarchy of
Makefiles, shell scripts, or maybe Twitter's Pants, which sort of looks like
Maven for Python but would probably need contributions to do what we want,
and looks predisposed to building PEX files which, while very interesting,
I'm not looking to do right now. None of these solutions are really ideal,
especially if I want to support development on Windows (which I absolutely
want).
I've even thought about actually using Maven, but that's just a Pandora's
box of problems waiting to happen.
I'd appreciate insight on this from anyone who's thought about (and maybe
solved) problems like this. I'm also willing to engage and contribute to
improving the situation, especially if there's low hanging fruit to be
picked. How do other companies handle large Python repositories with a lot
of subcomponents?
Checkout Buildout, http://www.buildout.org
It addresses a lot of the same problems. Of course, for Python, compiling is
(mostly) not all that important. For us (Zope Corporation) buildout
is more about
assembly/deployment, both for development and production, that building.
Jim
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
