5 ms·

I don't want to learn another build system. why would I?

by billconan 12y ago

prezjordan 12y ago
What a strange attitude.
- serge2k 12y ago
  why? What problem does this solve that hasn't been solved many times already?
  - sulam 12y ago
    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.
    - theboywho 12y ago
      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?
      - lahosken 12y ago
        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.
    - mercurial 12y ago
      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?
      - lahosken 12y ago
        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'.
        mercurial 12y ago
        But in this case I don't want to skip all tests, just the slow ones. Or say I want to add a goal to generate compressed CSS. Can I do that?
        lahosken 12y ago
        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/pants_test/targets/BUILD 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 http://pantsbuild.github.io/howto_customize.html
        mercurial 12y ago
harryh 12y ago
Fine grained dependency management for large projects that large teams work on.
- beagle3 12y ago
  I only skimmed through the documentation, so I must have missed something, but I fail to see how it can be better than either redo[0] or tup[1] in either speed or dependency tracking. [0] http://apenwarr.ca/log/?m=201012#14 http://apenwarr.ca/log/?m=201012#14 - designed by djb, implemented by apenwarr. [1] http://gittup.org/tup/ http://gittup.org/tup/ - the fastest build system you'll ever meet, with an essentially perfect automatic dependency tracker
  - harryh 12y ago
    shrug Haven't messed with redo or tup. Maybe they do great dependency tracking as well. It's not a new idea. Pants is basically a copy of Google's build system by a bunch of ex-Googlers. Pants also does nifty things like artifact caching between members of a team which is nice. It will continue to do more nice things in the future as it's under active development by a decent number of people at this point.
    - beagle3 12y ago
      tup does perfect instantaneous dependency tracking: It monitors file system access to see which files were accessed during build (you don't have to tell it). It does not depend on tool co-operation, and it's the only build system that will figure out that you've upgraded your compiler (e.g. if javac or gcc was replaced) and thus a rebuild is in order. redo is explicit; it doesn't automatically do dependency tracking, you have to tell it what went it. But it's fast and incredibly elegant - it's extremely easy to make it track any dependencies you know about, and it's built for easily rebuilding just a part of your system.

I don't want to learn another build system. why would I?

prezjordan 12y ago

What a strange attitude.

serge2k 12y ago
why? What problem does this solve that hasn't been solved many times already?
- sulam 12y ago
  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.
  - theboywho 12y ago
    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?
    - lahosken 12y ago
      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.
  - mercurial 12y ago
    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?
    - lahosken 12y ago
      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'.
      - mercurial 12y ago
        But in this case I don't want to skip all tests, just the slow ones. Or say I want to add a goal to generate compressed CSS. Can I do that?
        lahosken 12y ago
        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/pants_test/targets/BUILD 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 http://pantsbuild.github.io/howto_customize.html
        mercurial 12y ago

harryh 12y ago

Fine grained dependency management for large projects that large teams work on.

beagle3 12y ago
I only skimmed through the documentation, so I must have missed something, but I fail to see how it can be better than either redo[0] or tup[1] in either speed or dependency tracking. [0] http://apenwarr.ca/log/?m=201012#14 http://apenwarr.ca/log/?m=201012#14 - designed by djb, implemented by apenwarr. [1] http://gittup.org/tup/ http://gittup.org/tup/ - the fastest build system you'll ever meet, with an essentially perfect automatic dependency tracker
- harryh 12y ago
  shrug Haven't messed with redo or tup. Maybe they do great dependency tracking as well. It's not a new idea. Pants is basically a copy of Google's build system by a bunch of ex-Googlers. Pants also does nifty things like artifact caching between members of a team which is nice. It will continue to do more nice things in the future as it's under active development by a decent number of people at this point.
  - beagle3 12y ago
    tup does perfect instantaneous dependency tracking: It monitors file system access to see which files were accessed during build (you don't have to tell it). It does not depend on tool co-operation, and it's the only build system that will figure out that you've upgraded your compiler (e.g. if javac or gcc was replaced) and thus a rebuild is in order. redo is explicit; it doesn't automatically do dependency tracking, you have to tell it what went it. But it's fast and incredibly elegant - it's extremely easy to make it track any dependencies you know about, and it's built for easily rebuilding just a part of your system.