yes, that seems reasonable. worth confirming with @happy-kitchen-89482, as it was his ambition to allow for removing config

Yes, we want to be able to run without a config file, not so much because this is overwhelmingly useful but because it proves something about the robustness of the options system.

@average-vr-56795 that's how the ij plugin finds pants and it seems like an extremely reasonable convention

Cool, thanks 🙂

If build graph traversals with multiple roots orderings changed but the contents stayed the same, would that be an issue for anybody?

also, is there anything that uses the leveled_predicate on build_graph outside of intransitive detection?

@fancy-queen-20734: i don't think "multiple roots" has any reasonable ordering, so no: that should be fine.

re: leveled_predicate... no, not that i know of

My approach in unifying traversals was to add a different predicate for dependency traversal that has the current target and the dependency as its parameters

with that and a lookup table for roots we can implement intransitive and strict_deps using the same code paths instead of having a special traversal impl for strict_deps

seems reasonable. a sketch of a design in a ticket somewhere would be useful

something like this https://github.com/pantsbuild/pants/issues/5149

probably won't be able to finish today, but making progress on the task fingerprinting ticket -- it gives `Optionable`s a fingerprint and uses the transitive closure of subsystem dependencies to find all applicable `option_scope`s for

Task

. there were multiple different ways to get that closure and not all of them were correct, so i'm trying to make

known_scope_infos()

the one true entry point to that information (i'm aware

known_scope_infos()

is different than what

Subsystem.closure()

returns). current diff is at +158/-197 lines and i'm gonna shrink it a lot before opening a PR. may be related to the rendering of option scopes in

options_reference.html

, but focusing on fixing #4966 (and #2739) for now

@aloof-angle-91616: hmm. interested to see it. afaik, the ticket only required one line of change

correct. the #2739 part inspired any differences

it would make sense to do the one line change first

i think there are bugs in the task fingerprinting in general though, so you probably ran into those.

potentially, but it was more learning what a task is that took the time to get to here. in the interest of progress i definitely think i can push up the #4966 fix then look into more intensive stuff afer

(i.e. much smaller)

well, post it and we can see whether it is worth splitting or not

or just landing together

ok, sounds like a plan

current is too broken to push but i can fix that in a bit

Does anyone know if python_binary support compatibility >= 3?

I have a fairly standard install of python 2.7 (at /usr/bin/python) and python 3.5 (at /usr/bin/python3) and pants is struggling to find a >= 3 interpreter

never mind, had a stale .pants.d, all is good 🙂

sorry about that... that bug is fixed in master (and thus in 1.4.0.dev20+), but will continue to exist in the 1.3.x series

Thoughts on https://github.com/pantsbuild/pants/issues/5158

shipit

A few of our test projects appear to be broken... If I make a whitespace change to testprojects/src/antlr/python/test/BUILD testprojects/src/java/org/pantsbuild/testproject/targetlevels/unspecified/BUILD or testprojects/src/protobuf/org/pantsbuild/testproject/import_from_buildroot/bar/BUILD I get errors running build-support/bin/isort.sh