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

    jolly-chef-92794

    03/07/2016, 11:30 PM
    (Things like pulling in a version 
    1.1.1
    of a jar instead of 
    1.1
    in tests vs. binary)
  • j

    jolly-chef-92794

    03/07/2016, 11:30 PM
    Maybe the things Twitter’s working on will make that easier.
  • j

    jolly-chef-92794

    03/07/2016, 11:32 PM
    (Though not all targets in our repo use the same versions of jars… so we can’t just pin all transitive deps globally, at least for now 😞)
  • w

    witty-crayon-22786

    03/07/2016, 11:32 PM
    yea, somewhat. but the solution in general is to reduce the total count of versions in the repo.
  • w

    witty-crayon-22786

    03/07/2016, 11:32 PM
    allowing folks to 
    managed
    their deps and have custom versions leads to more builds
  • w

    witty-crayon-22786

    03/07/2016, 11:33 PM
    the compiler is seeing that jar
  • w

    witty-crayon-22786

    03/07/2016, 11:33 PM
    with strict_deps on, it won't see the jar
  • w

    witty-crayon-22786

    03/07/2016, 11:34 PM
    ...but currently 
    invalidate_dependents
    would still be true for a strict_deps target, so
  • j

    jolly-chef-92794

    03/07/2016, 11:35 PM
    In the case I found last week it wasn’t a jar that we were even directly referencing; it was a library that was never mentioned anywhere in the repo. It’s just that some of the libraries we did depend on transitively depended on either 
    1.1
    or 
    1.1.1
    . So depending on which (seemingly unrelated) targets we compiled together, we got different transitive jar resolution
  • j

    jolly-chef-92794

    03/07/2016, 11:36 PM
    So this wasn’t a problem of having multiple 
    managed
    dependencies sets
  • j

    jolly-chef-92794

    03/07/2016, 11:37 PM
    It’s just that we had 
    B
    -> 
    A:1.1
    , and 
    C
    -> 
    A:1.1.1
    transitively. And depending on whether you happened to use 
    B
    or 
    C
    or both, the default ivy strategy would either resolve 
    A:1.1
    or 
    A:1.1.1
  • w

    witty-crayon-22786

    03/07/2016, 11:38 PM
    @jolly-chef-92794: yea, exactly. but the compiler sees transitive deps.
  • w

    witty-crayon-22786

    03/07/2016, 11:38 PM
    see above.
  • w

    witty-crayon-22786

    03/07/2016, 11:38 PM
    and hence, we invalidate for them
  • w

    witty-crayon-22786

    03/07/2016, 11:39 PM
    hiding the transitive deps is what 
    strict_deps
    does
  • j

    jolly-chef-92794

    03/07/2016, 11:39 PM
    Ah, so 
    strict_deps
    makes ivy ignore transitive dependencies that aren’t explicitly asked for?
  • w

    witty-crayon-22786

    03/07/2016, 11:39 PM
    not ivy
  • w

    witty-crayon-22786

    03/07/2016, 11:39 PM
    but zinc
  • j

    jolly-chef-92794

    03/07/2016, 11:39 PM
    Hmm
  • j

    jolly-chef-92794

    03/07/2016, 11:39 PM
    What about codegen?
  • j

    jolly-chef-92794

    03/07/2016, 11:39 PM
    Will proto libraries still be invalidated?
  • j

    jolly-chef-92794

    03/07/2016, 11:40 PM
    Transitively invalidating the java_libraries that depend on them?
  • w

    witty-crayon-22786

    03/07/2016, 11:40 PM
    yes
  • w

    witty-crayon-22786

    03/07/2016, 11:40 PM
    for the same reason
  • w

    witty-crayon-22786

    03/07/2016, 11:40 PM
    er, no
  • w

    witty-crayon-22786

    03/07/2016, 11:40 PM
    @jolly-chef-92794: each task exists in isolation
  • w

    witty-crayon-22786

    03/07/2016, 11:41 PM
    if you don't pass 
    self.invalidated(..., invalidate_dependents=True)
    , then a target will only be invalidated if it literally changed.
  • w

    witty-crayon-22786

    03/07/2016, 11:41 PM
    otherwise, it will be invalidated if anything in its dep graph changes.
  • b

    bored-art-40741

    03/07/2016, 11:42 PM
    Yeah, that's just switching between 
    target.invalidation_hash
    and 
    target.transitive_invalidation_hash
    under the hood
  • w

    witty-crayon-22786

    03/07/2016, 11:42 PM
    and in fact, we don't have an invalidation equivalent of 
    strict_deps
    , but we probably need it.
1...103510361037...2420Latest