[Distutils] Enterprise Python - Multicomponent Projects

Tin Tvrtković tinchester at gmail.com
Wed Apr 16 22:27:13 CEST 2014

Hi Brian, thanks for the reply.

I'm definitely excited about Pants. I see there's a pants-users group 
now, but it's currently empty (as in zero posts - crickets and 
tumbleweeds :) ). Would that be a good place to ask questions when I get 
around to playing with Pants?

It also looks like Pants development is very active right now. Would you 
suggest waiting a while before diving into the docs and code? I don't 
really need Pants to be super easy to use (your suggested one year 
period), just to be able to understand it and maybe write a few modules 
I need. I guess I'm asking if the core is stable enough for semi-serious 
plugin development.


On 16.04.2014 19:32, Brian Wickman wrote:
> Pants can definitely do what you want, but you're probably right in 
> that it requires significant up-front investment.  It's not strictly 
> tied to PEX files (it can recursively generate setup.py-based projects 
> from a transitive closure of BUILD dependencies) but the learning 
> curve is non-trivial and most attention is given to the Java/Scala 
> backends.  Python support will improve over time but it may be a year 
> or more before this is really easy to adopt.
> ~brian
> On Wed, Apr 16, 2014 at 12:18 PM, Tin Tvrtković <tinchester at gmail.com 
> <mailto:tinchester at gmail.com>> 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?
>     Kind regards,
>     Tin
>     _______________________________________________
>     Distutils-SIG maillist  - Distutils-SIG at python.org
>     <mailto:Distutils-SIG at python.org>
>     https://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20140416/7b864624/attachment.html>

More information about the Distutils-SIG mailing list