https://pantsbuild.org/ logo
Join Slack
Powered by
I am a bit confused about the caching mechanism be...
# general
b
I am a bit confused about the caching mechanism behind pants. I have a file with some unit tests, and if I run the tests with 
pants test --debug path/to/test_file.py
The tests run just fine. If I however run them with 
pants test ::
I get failing tests, which I have already removed from the test file. What am I missing here?
e
The :: is a glob that says run all tests everywhere in the repo. The path to a file says test just this file (I'll ignore the --debug wildcard difference you threw in there for now).
b
I see that the debug flag does not change anything. But why could the :: glob ignore the changes I have made to the test file. I can remove the failing tests from the test file, but I still get them as failed tests...
e
Are you on Windows?
b
No
Linux (ubuntu)
e
I'm not sure then. The Pants daemon (pantsd) is on by default and uses a filesystem watcher. It should have picked up edits to any files in you repo owned by targets. On Windows there is a well known case where the Windows <-> WSL filesystem interface is a network filesystem which does not support watching and so you get stale results like this if your project is in /mnt/c but you run inside WSL Linux.
b
Can I somehow clear the cache and all temp files?
e
That won't be useful here. We need to solve the file watch problem.
First debug step, kill the pants daemon and the re-run. I use 
pkill pantsd
Use ps to make sure it's down, then try again. If this works we have narrowed the issue to file system watching.
b
It is down. If I run again "pants test ::", I still get the same error (61 tests failed, 12 passed, even though I have removed all of these tests but three)
e
And you've removed them how exactly? Can you provide the BUILD file diff if that's how you did it or describe the procedure in detail. Did you delete test files themselves?
b
Just commented them out in the python file. I made no change to the BUILD file.
e
Ok, what do you get if you remove the confusing - I think likely irrelevant - --debug from the 1st invocation? Still the answer you expect?
b
If I do that it works as I would expect. It finds the three remaining tests, and evaluates them successfully.
e
What about 
./pants test path/to:
?
b
Then it runs successfully (as it does with the 1st invocation).
e
Ok, and 
./pants test path::
- as you can see, just walking back up the filesystem expanding the glob here until the problem is hit.
b
Thank you. I found the root cause of the issue. I was restructuring the repo, and it seems like this file was located in two places 😕
e
Aha, ok. Great.
b
Walking up the directory tree helped me identify the issue.
On related notes, the test file path/to/test_file.py depends on some data stored under path/to/data/some_data.txt. Should the data folder have a BUILD file that defines a resource, or should it be located under path/to/BUILD?
e
Totally up to you. The only rule is that the BUILD file is somewhere in the lineage from the file's parent dir all the way back up to repo root. Any one of those dirs + your evaluation of what is sane and understandable for the folks you work with.
BUILD files define targets that own files in their subtree is the rule.
Dependencies, however, can point anywhere in the repo.
b
Great to hear. Right now I have something like
Copy code
python_tests(dependencies=[":test_data"]
resources(name="test_data", sources=["data/*.txt"])
in the /path/to/BUILD file and no BUILD file under the data folder.
I have multiple test files under /path/to/ but it is only one of those that actually depends on the test files. Can I somehow make the dependency declaration more fine grained?
e
Yes, just a sec for a link.
See if that helps you figure it out / the concept out. Better to start with 2nd link for the concept.
b
Great. I will check this out; thank you again for your help.
7 Views
Open in Slack
PreviousNext
Powered by