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

    happy-kitchen-89482

    08/21/2015, 3:19 AM
    Anyway, that's all fine, except that we don't show recursive options in non-advanced help.
  • h

    happy-kitchen-89482

    08/21/2015, 3:19 AM
    So 
    ./pants help repl.scala
    doesn't show help for 
    jvm.repl.scala
    .
  • h

    happy-kitchen-89482

    08/21/2015, 3:19 AM
    The yak shave was to instead re-register all the subsystem options on the inner scope.
  • h

    happy-kitchen-89482

    08/21/2015, 3:20 AM
    This also had the nice property of no longer requiring you to remember to make all your subsystem options recursive.
  • e

    enough-analyst-54434

    08/21/2015, 3:20 AM
    That fallout will be nice
  • h

    happy-kitchen-89482

    08/21/2015, 3:20 AM
    It made it so that only global options (like 
    --level
    ) can be recursive.
  • h

    happy-kitchen-89482

    08/21/2015, 3:20 AM
    Which was the intent of recursive all along.
  • e

    enough-analyst-54434

    08/21/2015, 3:20 AM
    It was ~redundant to .scoped(...)
  • h

    happy-kitchen-89482

    08/21/2015, 3:21 AM
    Subsystems are always intended to have different values in 
    jvm.repl.scala
    and 
    jvm
    , so the recursive=True was semantically redundant.
  • h

    happy-kitchen-89482

    08/21/2015, 3:22 AM
    However...
  • h

    happy-kitchen-89482

    08/21/2015, 3:22 AM
    Re-registering the options on 
    jvm.repl.scala
    has the unfortunate side-effect of severing the ability of the inner option value to fall back to the outer scope.
  • h

    happy-kitchen-89482

    08/21/2015, 3:23 AM
    So setting 
    --foo=1
    in 
    jvm
    would no longer have the effect of setting it in 
    jvm.repl.scala
    , when its value isn't specified explicitly in that inner scope.
  • h

    happy-kitchen-89482

    08/21/2015, 3:23 AM
    Maybe that's actually what we want? I don't think so though.
  • e

    enough-analyst-54434

    08/21/2015, 3:24 AM
    Yeah - I don't think so
  • h

    happy-kitchen-89482

    08/21/2015, 3:24 AM
    So, my further yak shave was going to be to get rid of that severing, and make all options always fall back to their parent scope, even if re-registered on the inner scope.
  • h

    happy-kitchen-89482

    08/21/2015, 3:25 AM
    But that means getting rid of the ability to shadow an option.
  • h

    happy-kitchen-89482

    08/21/2015, 3:25 AM
    However I think there's an easier way
  • e

    enough-analyst-54434

    08/21/2015, 3:25 AM
    A scoping on a Subsystem says not global recursive, but auto recurse down my lineage
  • h

    happy-kitchen-89482

    08/21/2015, 3:25 AM
    Yes, I think that's what it should mean. Otherwise we're requiring people to set values on every inner scope, which is ridic.
  • h

    happy-kitchen-89482

    08/21/2015, 3:27 AM
    However I think an easier solution would be to just show recursive options in help output, if they came from a subsystem.
  • h

    happy-kitchen-89482

    08/21/2015, 3:27 AM
    We could also default recursive=True for subsystems, to solve the problem of requiring explicit recursive=True on every single subsystem option.
  • h

    happy-kitchen-89482

    08/21/2015, 3:28 AM
    Re-registering on an inner scope is too big a change from how things work right now, and it will break a lot of current command lines, unless we also change the semantics of re-registering, and get rid of shadowing.
  • h

    happy-kitchen-89482

    08/21/2015, 3:30 AM
    So I think I'll do it that way
  • g

    gorgeous-fish-11040

    08/21/2015, 2:45 PM
    Hey @enough-analyst-54434, what do you think about pointing 
    interpreter_cache_dir
    and 
    resolver_cache_dir
    in 
    [pants-setup]
    to 
    local_artifact_cache
    so it will survive clean-all. I ran 
    ./pants clean-all test examples/tests/python/:: --time | grep main:test:pytest:run:chroot
    twice with the current pants.ini and got 6-7 seconds. Then I changed these options to point to dirs in 
    local_artifact_cache
    and ran it several times again and got 6 seconds first time and just 1.5 seconds each next time.
  • e

    enough-analyst-54434

    08/21/2015, 2:51 PM
    +1
  • g

    gorgeous-fish-11040

    08/21/2015, 2:55 PM
    Perfect. The only issue might be if you’ll get a corrupted requirement in this global cache somehow then you are screwed. Seems I see one such case in our CI.
  • b

    bored-art-40741

    08/21/2015, 3:00 PM
    I am wary of this
  • b

    bored-art-40741

    08/21/2015, 3:01 PM
    .local_artifact_cache
    has a well defined meaning: it's where the artifact cache mechanism writes local artifacts and mirrors remote artifacts. Using it for something similar but otherwise unrelated is kind of weird
  • b

    bored-art-40741

    08/21/2015, 3:01 PM
    On the other hand, hidden subdir proliferation is not good either
  • g

    gorgeous-fish-11040

    08/21/2015, 3:06 PM
    I can introduce a new one 
    local_python_cache = %(pants_bootstrapdir)s/python_cache
    like we have for 
    local_artifact_cache
1...200201202...2420Latest