[Distutils] Enterprise Python - Multicomponent Projects

Tin Tvrtković tinchester at gmail.com
Wed Apr 16 18:18:16 CEST 2014


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?

Kind regards,
Tin


More information about the Distutils-SIG mailing list