https://pantsbuild.org/ logo
Join Slack
Powered by
2) make the local v2 runner run in something that ...
# development
w
2) make the local v2 runner run in something that is not a subdirectory of 
.pants.d
, which would break these in the local case as well
...and then have a single blacklist for both local and remote
h
don’t want a single blacklist, as there are failures unrelated to this issue
w
ok. i think that in the long run we want the local and remote behavior to be as close as possible to identical (although remote will always have better sandboxing)
👍 1
so we might have to do this anyway at some point
but fine with waiting.
h
i think that in the long run
and in the long long run (but hopefully not too long), no blacklist 🙂
w
yep
h
I think https://github.com/pantsbuild/pants/pull/8066 might fix most the issues. Let me test. (Unless that PR is not acceptable)
w
it sounded like you said that the 
//:
part wasn't accurate
assuming that part gets figured out and we're able to apply relevant 
files
targets to get things pulled in, then yea... i think that should be ok.
h
I couldn’t get the 
//:
part working before. But now it seems like it is working! The PR would end up being what I have up (minus a typo)
w
oh. yea, that should be great then.
note that the other alternative (and this is probably more portable?) would be to have the base test class write out stable copies of those files during its initialization
h
note that the other alternative (and this is probably more portable?) would be to have the base test class write out stable copies of those files during its initialization
Sure, but that would still require using 
files
for those targets so that the base test class can access the original versions.
Oh, or do you mean 
python_test_runner.py
?
w
no, i mean 
test_base
unit tests can create files in their buildroot
so you could think of an override near the end of in 
def setUp
to call 
self.create_file('BUILD.tools', '$somehardcodedcontent')
Open in Slack
PreviousNext
Powered by