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

    witty-crayon-22786

    04/14/2017, 9:56 PM
    ...post fork i guess?
  • r

    rough-minister-58256

    04/14/2017, 9:56 PM
    yeah, top level runner has forked at that point
  • r

    rough-minister-58256

    04/14/2017, 9:56 PM
    it killing the daemon is another issue
  • r

    rough-minister-58256

    04/14/2017, 9:57 PM
    for subsequent calls
  • w

    witty-crayon-22786

    04/14/2017, 9:57 PM
    but it kills it "effectively synchronously", no?
  • w

    witty-crayon-22786

    04/14/2017, 9:57 PM
    the async part is just the file removal
  • w

    witty-crayon-22786

    04/14/2017, 9:57 PM
    so when the command returns to the client, the daemon is dead
  • r

    rough-minister-58256

    04/14/2017, 9:57 PM
    eh
  • r

    rough-minister-58256

    04/14/2017, 9:59 PM
    the async part I think leads to removal of the pantsd.log out from underneath while an in-flight run is in process.
  • w

    witty-crayon-22786

    04/14/2017, 10:01 PM
    maybe. my understanding was that the synchronous portion was "move this to another location", and then the async portion was removing it
  • r

    rough-minister-58256

    04/14/2017, 10:01 PM
    either way, seems like there’s a quickish lifecycle fixup therein
  • w

    witty-crayon-22786

    04/14/2017, 10:01 PM
    yea, i think so.
  • w

    witty-crayon-22786

    04/14/2017, 10:01 PM
    even if it moved it, the file handle should still be good though, i think?
  • b

    billowy-beach-68498

    04/17/2017, 3:00 PM
    @witty-crayon-22786 how can I help with 1.3.0 milestone? should I pick an issue from https://github.com/pantsbuild/pants/milestone/8 or something else?
  • w

    witty-crayon-22786

    04/17/2017, 3:21 PM
    @billowy-beach-68498 : yea, unassigned issue from the milestone
  • w

    witty-crayon-22786

    04/17/2017, 6:57 PM
    @happy-kitchen-89482 : ivy resolution and tests aren't isolated
  • w

    witty-crayon-22786

    04/17/2017, 6:57 PM
    ivy because the resolve happens for the entire context, rather than one per root
  • h

    happy-kitchen-89482

    04/17/2017, 6:58 PM
    Right
  • h

    happy-kitchen-89482

    04/17/2017, 6:58 PM
    and the same thing is now true for Python
  • w

    witty-crayon-22786

    04/17/2017, 6:58 PM
    and tests, because all in one jvm, rather than one per root
  • h

    happy-kitchen-89482

    04/17/2017, 6:58 PM
    So we can’t currently support the “slow” test running feature that created isolated chroots per test target
  • w

    witty-crayon-22786

    04/17/2017, 6:59 PM
    is it not possible to compute the subset of the resolve that the target uses?
  • h

    happy-kitchen-89482

    04/17/2017, 6:59 PM
    We can reintroduce at the engine level, by effectively expanding 
    ./pants test foo bar
    into 
    ./pants test foo
    ./pants test bar
  • w

    witty-crayon-22786

    04/17/2017, 7:00 PM
    with jvm tests, we can compute the portion of the graph that a target needs
  • h

    happy-kitchen-89482

    04/17/2017, 7:00 PM
    But what would you do with 
    ./pants test ::
    ?
  • w

    witty-crayon-22786

    04/17/2017, 7:00 PM
    but the graph will have already been affected by ivy resolve
  • h

    happy-kitchen-89482

    04/17/2017, 7:00 PM
    What do you do if two tests have conflicting jar deps?
  • w

    witty-crayon-22786

    04/17/2017, 7:00 PM
    @happy-kitchen-89482 : it doesn't work now.
  • h

    happy-kitchen-89482

    04/17/2017, 7:00 PM
    Right
  • h

    happy-kitchen-89482

    04/17/2017, 7:00 PM
    My point is that the same is true for Python now, and for the same reason
1...313314315...906Latest