https://pantsbuild.org/ logo
Join Slack
Powered by
Which behavior do we think is more offensive? a) ...
# development
h
Which behavior do we think is more offensive? a) 
./pants test project
runs tests in 
project
and 
project/subdir
because you are using 
python_tests(sources=['**/*_test.py'])
b) 
./pants list project
only shows "atom" targets and generated targets: not target generators. You have to use 
project:
to include the target generators I can't find a way to avoid both problems
🅰️ 2
🅱️ 1
I personally find part a, 
./pants test project
, more offensive. i think intuitively, you would expect to only run tests in the folder and not subdirs It's a bummer to not show target generators w/ project introspection, but doesn't seem like a huge deal. Target generators are only for boilerplate reduction. And we keep moving that way: 1. Soon, they won't even have addresses 95% of the time! (
name=
proposal) 2. Already, they don't have most fields anymore like 
dependencies
and 
interpreter_constraints
because they are "moved"
further, Benjy and friends have been pushing more and more against 111. Which means a) is very offensive While I'm still not convinced we want to give up 111, having the option is a good thing
cool, this was very easy to implement
b
Don't forget that touching a build file invalidates every target in it for --changed It's the only reason I still can't advocate for using subdir globs
➕ 1
w
a) seems like exactly what someone coming from a project-centric world would expect
those recursive cases are (typically) when you’ve declared “a project”. so 
./pants test $project
actually doing the recursive thing makes sense
Which means a) is very offensive
i don’t think so? because you won’t have declared recursive globs
h
Hmm. If the contents of a BUILD file determine whether 
./pants test project
runs recursively or not then we're forcing all users to be aware of the nuances of targets. And the target is no longer "metadata attached to source files" but also binds those files together in non-obvious ways. I could change the structure of my targets in a way that until today was a no-op and suddenly different sets of tests run for the same CLI command.
💯 1
☝️ 2
➕ 1
h
if you want to do 
./pants test $project
, why not just do 
./pants test project::
?
very well said, Benjy and reminder we have 
./pants test project:
if you want the current behavior
h
At the risk of sounding like a broken record on this, it feels like another example of "targets as descriptive metadata" and "targets as ways of selecting things to act on" getting a little mixed up
💯 1
➕ 2
But then those are also still mixed up in my mind, so I could be wrong about all of this
h
When you do want to treat the target generator as something to run against (which will soon require 
name=
to be set), your options would be: • address literal spec • 
dir:
• 
dir::
b
Yeah, to me 
project
is the name of a directory. It might be the name of the project. But it also might not be. But it's always a directory. So do the normal directory thing.
➕ 1
w
As long as 
dir:
still exists I don't feel strongly about it.
h
sweet. yes, 
dir:
stlil exists and this was surprisingly very very easy to implement 🙂
b
FWIW I don't disagree with Stu's point. Beginners intuition might be wrong and they might stumble. But I don't think that's a good enough reason to not do the "normally" intuitive thing.
w
Eric's point about soon needing to name the target in order for 
dir
vs 
dir:
to be different is maybe relevant too... that's a signal of intent.
➕ 1
b
I'll say Pants support of file/dir specs are part of why I love it. I can copy and paste paths and it works. Unlike bazel where I have to remember the target name or the triple dots ("back in my perforce days...")
Open in Slack
PreviousNext
Powered by