The blog post goes into details, but the main advantage pants has over other build systems we could have used is that it is designed from the ground up for a large codebase that is broken up sensibly into modules, libraries, or projects. It is smart about what it builds (or more importantly: what it doesn't build) and operates from the conception that most of the code you work with is available to be changed in any given commit. This is very much not the style that other build systems support, where trying to work in this way either results in a huge, undifferentiated pile of code or forces you to completely break things up entirely (ie work on stable dependencies). Once you have a significant number of engineers, this becomes inefficient whichever way you go -- either by giving you long build times or by making it unnatural to work outside your project.
We are a team of 25 engineers working on the same sbt based project. I don't see why we would move to pants. Do you have any non-marketing reason for why Pants is better than sbt?
Maybe, maybe not. As your codebase grows, it's likely to turn into separate parts with some common code. Pants can get you faster incremental builds: quickly figuring out what needs building, building just that. If sbt is quick for you, you might not have hit the point where Pants helps.
If you reach a point where sbt gets slow and you're looking at other build tools, that's a good time to look at Pants.
What concerns me is that it doesn't seem possible (based on a quick overview) to modify the default lifecycle, eg, to avoid running integration tests by default. How would you approach this problem?
When you invoke Pants, you pass in "goals" (roughly, the verbs/actions you want to take) and "targets" (roughly, the things you want to act upon, often piles of source code).
If you usually invoke './pants goal test bundle src/my/awesome/project tests/my/awesome/project' (to run tests and bundle up an app), to skip testing instead invoke './pants goal bundle my/awesome/project'.
To skip slow tests (except when you want them), you put them into separate targets and then don't invoke them on the command line (except when you want them). At the risk of tossing you in the deep end with a link to a big build config file, https://github.com/pantsbuild/pants/blob/master/tests/python... shows some Python tests that have been grouped into test suites. One of those test suites is named "integration". When folks want to run the fast tests, they invoke on tests/python/pants_test/targets target; when they want the slow tests, they invoke on tests/python/pants_test/targets:integration.
Yes, you can add a goal to generate compressed CSS. The docs are, alas, still skimpy, but they're getting better; meanwhile, they give an inkling: http://pantsbuild.github.io/howto_customize.html
