[Distutils] Enterprise Python - Multicomponent Projects

Brian Wickman wickman at gmail.com
Thu Apr 17 01:36:26 CEST 2014

pants-users is brand new, hence no activity.  most activity is on
pants-devel (and the sister list, pants-reviews.)

the pants execution engine was refactored a couple years ago (the "goal"
framework) and the java/scala pipelines were ported to that.  the python
backend is currently legacy and needs to be ported, but due to codebase
fracturing has been delayed.  you should likely wait until that is done
before you write any plugins, as they would need to be rewritten after the
port is finished.  if you are interested in helping with the port,
pants-devel is the right place to go.

On Wed, Apr 16, 2014 at 4:27 PM, Tin Tvrtković <tinchester at gmail.com> wrote:

>  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.
> Cheers!
> 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>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
>> 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/c9f91921/attachment-0001.html>

More information about the Distutils-SIG mailing list