https://pantsbuild.org/ logo
Join Slack
Powered by
Expanded conversation about partitioning by interp...
# development
h
Expanded conversation about partitioning by interpreter constraints not interacting well with parametrizing by interpreter constraints. Specifically, parametrizing 
python_tests
targets by, say, 6 different ICs, so that you can run tests on multiple interpreters, causes flake8 to run 6 times, on 6 different interpreters but on the same underlying test source files.
On some level this behavior is "correct" - flake8 can supposedly return different results when run on different interpreters (although possibly this is just a python2/python3 thing?). But in real world scenarios it is obviously ridiculous to do.
Thoughts on how to remedy this?
One option is to allow specifying a single IC for flake8, as we do for other tools, and if specified just use that instead of partitioning.
Note that the issue is with 
./pants lint ::
, of course one can do 
./pants lint path/to/tests@interpreter_constraints=py36
or whatever, but that is not awesome to force users into
Another option is, when partitioning, to take "same actual source file" into account
This is touched on in https://github.com/pantsbuild/pants/issues/14725 and I have commented there, because I think the comments on that issue don't take this use case into account in their claim that parametrizing is a "high bar" that justifies all that extra work
And in any case, having 
./pants lint ::
do the expected thing seems pretty basic
c
Maybe we need an “unparametrize” operation, that given a set of targets can merge them back down on those parametrized fields that are “mergeable” at the time. Such as ICs for a lint operation.
Or simply pick one, and drop the siblings instead of merging.
w
@curved-television-6568: your comment from https://github.com/pantsbuild/pants/issues/14725#issuecomment-1072241254 is relevant, i think. if the linter doesn’t actually care about differences between targets, it can broaden its constraints. but i commented on the ticket, because i didn’t think that we were partitioning by ICs anyway.
👍 1
…oh. lies. we do partition, but just not by transitive dependencies. will update the comment.
Open in Slack
PreviousNext
Powered by