-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/16/2014 12:57 PM, Jim Fulton wrote: > On Wed, Apr 16, 2014 at 12:18 PM, Tin Tvrtković <tinches...@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? > > 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.
buildout also allow for reproducible builds of things that *do* require compilation (e.g., via the 'zc.reciple.cmmi' recipe for 'configure-make-make install' software). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlNOwLcACgkQ+gerLs4ltQ46aACgts47yE/ErKtqag0FyOEpfCZP 4pAAoI8d04UodGt3NQB0AzPPJbJITPb/ =vBpI -----END PGP SIGNATURE----- _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig