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

    witty-crayon-22786

    03/18/2016, 4:35 PM
    not if the scope differentiates
  • w

    witty-crayon-22786

    03/18/2016, 4:35 PM
    ...whether it is transitive or not
  • w

    witty-crayon-22786

    03/18/2016, 4:35 PM
    or one hop, etc
  • j

    jolly-chef-92794

    03/18/2016, 4:36 PM
    I think putting the scope on the dependency targets would create excessive indirection and dummy targets
  • w

    witty-crayon-22786

    03/18/2016, 4:37 PM
    but yea, i definitely wonder whether the "anyone who depends on this will want it at a certain scope" cases outnumber the other
  • w

    witty-crayon-22786

    03/18/2016, 4:37 PM
    @jolly-chef-92794: not for any of the examples in the doc though, afaict?
  • w

    witty-crayon-22786

    03/18/2016, 4:37 PM
    hadoop, annotation processors, etc
  • j

    jolly-chef-92794

    03/18/2016, 4:38 PM
    Any time you had a provided dependency on a common library, you’d need something like
    Copy code
    java_library(name=‘lib’,
  dependencies=[
    ‘provided-3rdparty-foobar’,
  ],
)

target(‘provided-3rdparty-foobar’,
  scope=‘provided’,
  dependencies=[
    ‘3rdparty:foobar’,
  ],
)
  • w

    witty-crayon-22786

    03/18/2016, 4:38 PM
    @jolly-chef-92794: what is a case where you'd do that though
  • w

    witty-crayon-22786

    03/18/2016, 4:40 PM
    i'm interested in the deep hadoop graph case in particular
  • j

    jolly-chef-92794

    03/18/2016, 4:40 PM
    (1) Because we’re using 
    managed_jar_libraries
    to generate most of our 3rdparty 
    jar_library
    targets, including things like hadoop artifacts, we don’t (and cannot) edit the scopes of the jar_libraries in 3rdparty directly
  • w

    witty-crayon-22786

    03/18/2016, 4:40 PM
    hm. but isn't that a really good case for dependency-level declarations?
  • j

    jolly-chef-92794

    03/18/2016, 4:41 PM
    (2) Unlike in maven, I’m not implementing a 
    test
    scope (which 
    provided
    encompasses in maven), so we need to add some jars as provided dependencies in library code, and direct dependencies in the test code
  • j

    jolly-chef-92794

    03/18/2016, 4:41 PM
    Because the tests need them at runtime, and the library code only needs it at compile time
  • j

    jolly-chef-92794

    03/18/2016, 4:42 PM
    But it seems silly to implement a 
    test
    scope in pants, when you can just make your test code depend on what it needs to
  • w

    witty-crayon-22786

    03/18/2016, 4:42 PM
    right.
  • w

    witty-crayon-22786

    03/18/2016, 4:43 PM
    i'm not sure the "tests need it at runtime, libraries need it at compiletime" bit disagrees with what i'm saying. the "it" here is stable
  • j

    jolly-chef-92794

    03/18/2016, 4:43 PM
    Well, if the scope is on the jar_library,
  • w

    witty-crayon-22786

    03/18/2016, 4:43 PM
    so i'm just hoping you guys have time to think about this before committing to a big change
  • j

    jolly-chef-92794

    03/18/2016, 4:43 PM
    You need two jar_libraries, or one jar_library with two 
    target()
    indirections
  • w

    witty-crayon-22786

    03/18/2016, 4:44 PM
    i see
  • w

    witty-crayon-22786

    03/18/2016, 4:45 PM
    ... still not completely convinced, but not sure how much time i have to think about it
  • w

    witty-crayon-22786

    03/18/2016, 4:46 PM
    -if the scope is indicating something like "runtime only"-
  • w

    witty-crayon-22786

    03/18/2016, 4:46 PM
    ah... right.
  • w

    witty-crayon-22786

    03/18/2016, 4:46 PM
    different applications for tests/binaries
  • j

    jolly-chef-92794

    03/18/2016, 4:47 PM
    Yeah
  • j

    jolly-chef-92794

    03/18/2016, 4:47 PM
    I need to eat lunch, but we can chat more about this later
  • a

    ancient-stone-50795

    03/18/2016, 4:51 PM
    @witty-crayon-22786: I think a classic case would be when you are defining an annotation processor defined in the repo. You'll want to actually depend on that class in tests, test libraries, other tools that are built on top of that annotation processor, but when it is actually used you'll want to use some kind of mechanism to exclude it from the runtime classpath. Same dependency, different scope depending on which target you are calling it from.
  • a

    ancient-stone-50795

    03/18/2016, 4:52 PM
    I think you can make it work either way if you introduce an intermediate 
    target()
    type that can change the dependency behavior, but I proposed that up front at the Summit and folks didn't seem to like it much.
  • w

    witty-crayon-22786

    03/18/2016, 4:53 PM
    @ancient-stone-50795: hm, i don't think so... in that case, anyone who depends on the annotation processor wants it only at compile time
1...106310641065...2420Latest