-
-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parametrized python_tests
and python_sources
in same package not lining up when using explicit dependencies
#20739
Comments
Sorry for the trouble; can you create a reduced example as a demonstration? |
I understand the issue here.. will see if I can come up with a fix for it. |
@ndellosa95 Can you share the relevant parts of your BUILD files for this (redacted as needed), just to make sure I test the right thing? Thanks :) |
Or, if you can confirm that this test matches what you have.. assert_generated(
generated_targets_rule_runner,
Address("demo", target_name="tst"),
dedent(
"""\
generator(
name='src',
sources=['src1.ext'],
**parametrize('b1', resolve='a'),
**parametrize('b2', resolve='b'),
)
generator(
name='tst',
sources=['tst1.ext'],
dependencies=['./src1.ext:src'],
**parametrize('b1', resolve='a'),
**parametrize('b2', resolve='b'),
)
"""
),
["src1.ext", "tst1.ext"],
expected_dependencies={
"demo/src1.ext:src@parametrize=b1": set(),
"demo/src1.ext:src@parametrize=b2": set(),
"demo/tst1.ext:tst@parametrize=b1": {
"demo/src1.ext:src@parametrize=b1",
},
"demo/tst1.ext:tst@parametrize=b2": {
"demo/src1.ext:src@parametrize=b2",
},
"demo:src@parametrize=b1": {
"demo/src1.ext:src@parametrize=b1",
},
"demo:src@parametrize=b2": {
"demo/src1.ext:src@parametrize=b2",
},
"demo:tst@parametrize=b1": {
"demo/tst1.ext:tsr@parametrize=b1",
},
"demo:tst@parametrize=b2": {
"demo/tst1.ext:tst@parametrize=b2",
},
},
) which does fail with a missmatched parametrization for the explicitly provided dependency:
|
Yes, it always selects the first target in the parametrization. |
…0768) When both a target and a explicitly provided dependency is using parametrize groups (the `**parametrize(..)` syntax), and the dependency does not explicitly provide the parametrization to use, pick the matching parametrization group with the target if available, rather than just the first one. Closes #20739
…0768) When both a target and a explicitly provided dependency is using parametrize groups (the `**parametrize(..)` syntax), and the dependency does not explicitly provide the parametrization to use, pick the matching parametrization group with the target if available, rather than just the first one. Closes #20739
…0768) When both a target and a explicitly provided dependency is using parametrize groups (the `**parametrize(..)` syntax), and the dependency does not explicitly provide the parametrization to use, pick the matching parametrization group with the target if available, rather than just the first one. Closes #20739
…erry-pick of #20768) (#20778) When both a target and a explicitly provided dependency is using parametrize groups (the `**parametrize(..)` syntax), and the dependency does not explicitly provide the parametrization to use, pick the matching parametrization group with the target if available, rather than just the first one. Closes #20739 Co-authored-by: Andreas Stenius <[email protected]>
…erry-pick of #20768) (#20779) When both a target and a explicitly provided dependency is using parametrize groups (the `**parametrize(..)` syntax), and the dependency does not explicitly provide the parametrization to use, pick the matching parametrization group with the target if available, rather than just the first one. Closes #20739 Co-authored-by: Andreas Stenius <[email protected]>
Describe the bug
I have a
python_source
target in the same directory as apython_test
target. Both are parametrized for multiple resolves/environments/interpreter constraints. Thepython_test
target in question does not import thepython_source
target but instead calls it via thesubprocess
module, so I have thepython_source
target as an explicit dependency of thepython_test
one. This is causing an error because thepython_test
target is grabbing the first parametrization as the dependency instead of the matching one.pants peek
output below:Pants version
2.19.1
OS
Intel Mac
The text was updated successfully, but these errors were encountered: