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

    jolly-chef-92794

    03/07/2016, 11:55 PM
    That is a source of thrashing, but it’s not the only reason
  • j

    jolly-chef-92794

    03/07/2016, 11:55 PM
    Because you can depend on two jars within the same managed_jar_dependencies() set, that depend on different transitive dependencies
  • j

    jolly-chef-92794

    03/07/2016, 11:55 PM
    And get the situation patrick was describing above
  • w

    witty-crayon-22786

    03/07/2016, 11:55 PM
    sure... but things are deterministic for that 
    managed_jar_dependencies
  • w

    witty-crayon-22786

    03/07/2016, 11:56 PM
    right?
  • j

    jolly-chef-92794

    03/07/2016, 11:56 PM
    Only for the jars it lists explicitly
  • w

    witty-crayon-22786

    03/07/2016, 11:56 PM
    exactly
  • j

    jolly-chef-92794

    03/07/2016, 11:56 PM
    Not the transitive closure of jars that are referenced externally
  • w

    witty-crayon-22786

    03/07/2016, 11:56 PM
    yes for the transitive closure
  • w

    witty-crayon-22786

    03/07/2016, 11:56 PM
    er...
  • w

    witty-crayon-22786

    03/07/2016, 11:56 PM
    hm. depends what ivy does when you pin things i suppose.
  • j

    jolly-chef-92794

    03/07/2016, 11:57 PM
    It doesn’t resolve jars that you pin but don’t depend on. And it doesn’t see their dependencies either
  • j

    jolly-chef-92794

    03/07/2016, 11:58 PM
    So the dependencies of a pinned jar 
    A
    only affect the resolution if you actually depend on 
    A
    somewhere in your build
  • w

    witty-crayon-22786

    03/07/2016, 11:58 PM
    right. so now you're talking about frozen resolutions
  • j

    jolly-chef-92794

    03/07/2016, 11:59 PM
    Yeah, split per-managed dependencies object
  • w

    witty-crayon-22786

    03/07/2016, 11:59 PM
    because you're not currently including the transitive deps in your managed_jar_dep objects
  • j

    jolly-chef-92794

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

    witty-crayon-22786

    03/07/2016, 11:59 PM
    the frozen path has two halves: the stuff you directly declare, and the rest, which is generated.
  • w

    witty-crayon-22786

    03/07/2016, 11:59 PM
    so yea, that's what nick has been working on.
  • j

    jolly-chef-92794

    03/07/2016, 11:59 PM
    Okay, that’s what I kind of thought (and was hoping)
  • j

    jolly-chef-92794

    03/08/2016, 12:00 AM
    Because we can just manually figure out all our external dependencies and add them to our managed_dependencies,
  • j

    jolly-chef-92794

    03/08/2016, 12:01 AM
    But (a) that’s tedious, and (b) it’s hard to maintain without an automated mechanism to check for staleness, and if the versions should be different
  • w

    witty-crayon-22786

    03/08/2016, 12:01 AM
    yep.
  • w

    witty-crayon-22786

    03/08/2016, 12:01 AM
    but again, the other angle (which we think is inevitable) is using strict_deps in more places
  • j

    jolly-chef-92794

    03/08/2016, 12:02 AM
    That seems complementary
  • w

    witty-crayon-22786

    03/08/2016, 12:02 AM
    (...but needs the change to invalidation)
  • j

    jolly-chef-92794

    03/08/2016, 12:03 AM
    Also safer, in the sense that as things currently are, our code can be potentially affected by dependencies of deeply chained pom.xml dependencies floating out in open source land.
  • j

    jolly-chef-92794

    03/08/2016, 12:03 AM
    Without anyone explicitly verifying them
  • w

    witty-crayon-22786

    03/08/2016, 12:03 AM
    well, they always will be. in the sense that runtime
  • w

    witty-crayon-22786

    03/08/2016, 12:04 AM
    note that changing strict_deps doesn't affect resolves. and you still eventually need the resolved version at runtime
1...103710381039...2420Latest