https://pantsbuild.org/ logo
Powered by
#general
  • w

    witty-crayon-22786

    03/07/2016, 11:43 PM
    (alternatively, new engine.)
  • j

    jolly-chef-92794

    03/07/2016, 11:44 PM
    So if I have a java_library 
    A
    that depends on a java_protobuf_library 
    B
    that depends on some 3rdparty jar_library 
    C
    , If 
    C
    changes, java_protobuf_library will be invalidated and rebuilt. Won’t the java_library be rebuilt too, or are you saying that it doesn’t invalidate it?
  • b

    bored-art-40741

    03/07/2016, 11:44 PM
    I think one thing to note carefully here is that the fingerprint for compilation of some target 
    A
    is changed by the 
    compile_classpath
    product entry for 
    A
  • b

    bored-art-40741

    03/07/2016, 11:45 PM
    If you have a smaller 
    compile_classpath
    , you're less likely to change the non-transitive zinc fingerprint of 
    A
  • b

    bored-art-40741

    03/07/2016, 11:45 PM
    The issue here, as I understand it, is entirely about when your target 
    A
    and its entire transitive dependency closure has not changed
  • b

    bored-art-40741

    03/07/2016, 11:46 PM
    It just happens to be compiled in the context of a larger closure, which as you demonstrated earlier, can mess up what ivy pulls in
  • b

    bored-art-40741

    03/07/2016, 11:47 PM
    When Ivy pulls in a different version, the 
    compile_classpath
    for 
    A
    changes--but if we're using 
    strict_deps
    , it is less likely to thrash
  • w

    witty-crayon-22786

    03/07/2016, 11:48 PM
    " 
    A
    and its entire transitive dependency closure _has not changed": if that were the case, then the fingerprint would not change
  • b

    bored-art-40741

    03/07/2016, 11:48 PM
    Yes it would
  • b

    bored-art-40741

    03/07/2016, 11:48 PM
    Because the fingerprint is based on the fingerprint strategy which for the special case of zinc compilation is based on the 
    compile_classpath
    product
  • b

    bored-art-40741

    03/07/2016, 11:48 PM
    So it happens to change out from under you at the last second
  • j

    jolly-chef-92794

    03/07/2016, 11:48 PM
    ^- yes, that exactly is what happens
  • j

    jolly-chef-92794

    03/07/2016, 11:49 PM
    Does strict_deps cause those jars to not end up in the compile_classpath, and thus not in the fingerprint?
  • w

    witty-crayon-22786

    03/07/2016, 11:49 PM
    ..ah, i see what you mean. yea.
  • b

    bored-art-40741

    03/07/2016, 11:49 PM
    That is the idea (I think), Stu can confirm
  • w

    witty-crayon-22786

    03/07/2016, 11:49 PM
    but it is correct for the fingerprint to change in this case.
  • b

    bored-art-40741

    03/07/2016, 11:49 PM
    Agreed
  • j

    jolly-chef-92794

    03/07/2016, 11:49 PM
    @witty-crayon-22786 yes it totally is
  • w

    witty-crayon-22786

    03/07/2016, 11:49 PM
    k
  • w

    witty-crayon-22786

    03/07/2016, 11:50 PM
    but yea, strict_deps needs to go further and not trigger invalidation when it is enabled.
  • b

    bored-art-40741

    03/07/2016, 11:50 PM
    I remember fighting this change a lot because I knew it was going to be a cache thrash nightmare, but I ended up being swayed by the argument that it was more correct (and by that point we were on pom-resolve so it doesn't affect us at all wrt cache thrash)
  • j

    jolly-chef-92794

    03/07/2016, 11:51 PM
    Yeah. The cache-thrash nightmare is definitely hitting us. But it’s not wrong.. we just need a better way to bring our dependencies into line
  • h

    happy-kitchen-89482

    03/07/2016, 11:52 PM
    @gentle-potato-32845: I worked closely with Govind for years. Tell him I said hi.
  • w

    witty-crayon-22786

    03/07/2016, 11:52 PM
    enabling strict_deps and adding an invalidation mode for it would be the most correct way, imo.
  • w

    witty-crayon-22786

    03/07/2016, 11:53 PM
    we eventually want more code on strict_deps, but we were hoping to get dep inference in place first.
  • j

    jolly-chef-92794

    03/07/2016, 11:53 PM
    What if there were a way to run an out-of-band step to resolve all the transitive dependencies of a 
    managed_jar_dependencies
    set of pinned jars, save that to a file (maybe check it into source control) and use that to pin transitive versions for that set of 
    managed_jar_dependencies
    ?
  • w

    witty-crayon-22786

    03/07/2016, 11:53 PM
    i don't think that helps?
  • j

    jolly-chef-92794

    03/07/2016, 11:54 PM
    As long as you don’t run builds with multiple things that use different managed_jar_dependencies, I think it should
  • w

    witty-crayon-22786

    03/07/2016, 11:54 PM
    but you do
  • w

    witty-crayon-22786

    03/07/2016, 11:54 PM
    that's why you thrash
1...103610371038...2420Latest