-
-
Notifications
You must be signed in to change notification settings - Fork 631
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
Pants tests induce PEXWarning from resolve package collisions #20586
Comments
Good catch! I would think it'd be good not to ship this and #20577 in a stable release, potentially we should have the new option default to This would relieve the pressure of needing to land potentially-broad changes to fix the underlying issues (which we presumably should fix) to unblock 2.20.0. Thoughts? |
(Chucked up #20590 with that idea, in case we want to go with it.) |
A default of Pants is already pretty chatty so I do lean towards |
Although now that I've thought through that a little more, we probably should keep it enabled for Pants itself (in |
This is a short-term workaround for #20577 and #20586, where Pants' internal/default use of Pex triggers user-visible warnings, and those warnings are now visible due to #20480... so, instead of showing them by default, let's hide them for now. Users with desire for insight into the warnings can still enable this. Doing this means we're not having to rush in fixes for the root causes of these warnings for 2.20.0 stable release, and thus reduce feature-creep/risk. We can/should reenable warnings by default in a future release. Per @cburroughs's idea in #20586 (comment), this explicitly switches it on for the Pants repo itself, so we're eating our own dogfood and catching real and/or spurious errors earlier.
This is a short-term workaround for #20577 and #20586, where Pants' internal/default use of Pex triggers user-visible warnings, and those warnings are now visible due to #20480... so, instead of showing them by default, let's hide them for now. Users with desire for insight into the warnings can still enable this. Doing this means we're not having to rush in fixes for the root causes of these warnings for 2.20.0 stable release, and thus reduce feature-creep/risk. We can/should reenable warnings by default in a future release. Per @cburroughs's idea in #20586 (comment), this explicitly switches it on for the Pants repo itself, so we're eating our own dogfood and catching real and/or spurious errors earlier.
…#20593) This is a short-term workaround for #20577 and #20586, where Pants' internal/default use of Pex triggers user-visible warnings, and those warnings are now visible due to #20480... so, instead of showing them by default, let's hide them for now. Users with desire for insight into the warnings can still enable this. Doing this means we're not having to rush in fixes for the root causes of these warnings for 2.20.0 stable release, and thus reduce feature-creep/risk. We can/should reenable warnings by default in a future release. Per @cburroughs's idea in #20586 (comment), this explicitly switches it on for the Pants repo itself, so we're eating our own dogfood and catching real and/or spurious errors earlier. Co-authored-by: Huon Wilson <huon@exoflare.io>
Removing this from the 2.20.x milestone, since we landed #20593 as a stop-gap to reduce severity in 2.20.0 |
Describe the bug
Several examples along the lines of:
That is we have one version of
typing_extensions
inpytest.lock
and a different version in (for example)user_reqs.lock
. "Normally" lockfiles are disjoint, but in the case of tools they are sometimes munged together.I'm not sure exactly what -- if anything -- should be done here. Or rather what the recommendation should be for Pants users in the same situation short of #9206
Pants version
2d1ffe9
OS
Are you encountering the bug on MacOS, Linux, or both?
Additional info
See also #20577
The text was updated successfully, but these errors were encountered: