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

    dry-analyst-73584

    10/07/2015, 8:09 PM
    So, do I put this issue on hold until the engine refactor?
  • e

    enough-analyst-54434

    10/07/2015, 8:10 PM
    @witty-crayon-22786: the point on this bug was the upfront resolve fails
  • e

    enough-analyst-54434

    10/07/2015, 8:11 PM
    you'd need a failure tolerant up-fronter that allowed you to edit the partial resolve list and iterate past the failure
  • w

    witty-crayon-22786

    10/07/2015, 8:11 PM
    or re-resolve periodically, yea
  • e

    enough-analyst-54434

    10/07/2015, 8:12 PM
    well, the resolve fails
  • w

    witty-crayon-22786

    10/07/2015, 8:12 PM
    right, but it's a cache
  • e

    enough-analyst-54434

    10/07/2015, 8:12 PM
    so you need to resort to writing the deps by hand
  • w

    witty-crayon-22786

    10/07/2015, 8:12 PM
    we can't stop doing anything while waiting for it to come back
  • w

    witty-crayon-22786

    10/07/2015, 8:12 PM
    s/anything/everything/
  • w

    witty-crayon-22786

    10/07/2015, 8:13 PM
    @dry-analyst-73584: re-resolving periodically is something we can do now, independent of the engine refactor
  • w

    witty-crayon-22786

    10/07/2015, 8:13 PM
    sorry, the speculation thing was too forward looking
  • d

    dry-analyst-73584

    10/07/2015, 8:13 PM
    speculation thing is pretty awesome though simple smile
  • f

    full-kilobyte-93429

    10/07/2015, 8:16 PM
    re-resolving periodically or upon failures or a combination of the two?
  • w

    witty-crayon-22786

    10/07/2015, 8:19 PM
    i don't know. i do begin to wonder whether a local finagle proxy would make more sense than continuing to implement this logic though =/
  • w

    witty-crayon-22786

    10/07/2015, 8:20 PM
    the 'resolver' interface is in place, so would be possible to put a wily name or something in there
  • d

    dry-analyst-73584

    10/07/2015, 8:21 PM
    The bug I’m looking at seems to be the result of using a configured cache before it has been resolved at all?
  • d

    dry-analyst-73584

    10/07/2015, 8:22 PM
    Or rather, attempting to use a cache of type “None”
  • w

    witty-crayon-22786

    10/07/2015, 8:22 PM
    then i might be conflating it with what peiyu is looking at. sorry
  • d

    dry-analyst-73584

    10/07/2015, 8:22 PM
    No worries
  • a

    ancient-stone-50795

    10/07/2015, 8:32 PM
    @enough-analyst-54434: Thank you for that workaround. I’ve updated our dep on pantsbuild.pants.testinfra to 0.0.52 and am pushing a change to re-enable our plugin tests now.
  • e

    enough-analyst-54434

    10/07/2015, 8:33 PM
    You're welcome
  • w

    witty-crayon-22786

    10/07/2015, 8:50 PM
    hm. just realized i was using 'resolve' in two different threads at once above. confusing.
  • w

    witty-crayon-22786

    10/07/2015, 10:04 PM
    @bored-art-40741: an idea for switching jvm compiles to the 'cache_target_dirs' mechanism:
  • w

    witty-crayon-22786

    10/07/2015, 10:04 PM
    record the "previous" cache key for targets
  • w

    witty-crayon-22786

    10/07/2015, 10:04 PM
    then copy artifacts from the old location to the new location before starting
  • w

    witty-crayon-22786

    10/07/2015, 10:05 PM
    this would mean that the artifacts under any particular cache dir would be immutable once completed
  • w

    witty-crayon-22786

    10/07/2015, 10:06 PM
    reason i'm thinking about this: we have requests internally to be able to run two copies of 
    ./pants run
    at once
  • w

    witty-crayon-22786

    10/07/2015, 10:08 PM
    and @most-cricket-96651 gave me the idea, heh.
  • m

    most-cricket-96651

    10/07/2015, 10:18 PM
    I don't remember saying that, but I'm happy to get credit. : )
  • w

    witty-crayon-22786

    10/07/2015, 10:19 PM
    @most-cricket-96651: the "book"... essentially, an ancestry in incremental compiles
1...513514515...2420Latest