Conversation
| Added the `[python].default_to_resolve_interpreter_constraints` option which when set the true, allows Python targets with both `interpreter_constraints` and `resolve` fields to fallback on their resolve's interpreter constraints before the global constraints if no interpreter constraints are set on the actual target. | ||
|
|
||
| The version of [Pex](https://github.com/pex-tool/pex) used by the Python backend has been upgraded to [`v2.73.1`](https://github.com/pex-tool/pex/releases/tag/v2.73.1). This fixes two issues: | ||
| The version of [Pex](https://github.com/pex-tool/pex) used by the Python backend has been upgraded to [`v2.76.1`](https://github.com/pex-tool/pex/releases/tag/v2.76.1). This fixes two issues: |
There was a problem hiding this comment.
In spite of 2.73.1 being the update that was referenced by the subsequent two bugs, I've just updated this here - as updating to 2.76.1 should have the same effect.
|
Part of the update of See #22814 |
|
Lol, what a failed test |
This appears to relate to Pex 2.74.2 on this PR: pex-tool/pex#3043 Note: I’m writing this from my iPad on the GitHub website, so, untested other than this upcoming CI run.
|
I knew my YOLO wouldn’t work… Will fix this when back at a machine. |
|
The pypa/packaging#935 Pex made this change in 2.74.2 (https://github.com/pex-tool/pex/releases/tag/v2.74.2) The associated inconsistent code is in Just outlining my observations so I don't forget them when I come back to this later today. |
|
@sureshjoshi am I correct that you're updating packaging just to fix a test that does string comparisons of requirements (and is failing on irrelevant white space differences) instead of comparing parsed requirement objects, for example? |
No. |
|
@sureshjoshi Ok, but I can't see why else. I'm sensitive to breaking folks with Pex, but spaces around There will be another coming up in 2.77.1 (@cburroughs filed #22988). That one I'm still not sure about. Pants is using |
|
Yeah, pex "broke Pants tests", but like... I don't consider that to be a true break either. The tests were/are brittle. I was investigating what else would break when the next packaging update comes down that contains that change upstream, and why we actually had a set of tests that didn't test the functionality - but did string compares at multiple places in multiple ways. Each change I tested failed a different assertion in that function - all related to the same whitespace issue. Pants is bogged down with brittle assertions (many of which I'm a contributor to), but the pex-related stuff has always been seamless, so I was documenting (mostly to myself) what I was finding along the way, as between holidays and CES, I knew I'd be swamped and unable to come back to this. I had some more observations I (apparently) didn't post from later that day, about some tangential investigations. I'll post them if I can dig them up, but in short, that function has a bunch of assertions about internals that I don't think we shouldn't be checking at all. |
|
Closed in favour of: #23003 Will update the requirements.txt and lockfile in a separate PR. |
Pull request was closed
Precursor to #22946
Lockfile diff: 3rdparty/python/user_reqs.lock [python-default] == Upgraded dependencies == lia-web 0.2.3 --> 0.3.1 packaging 25.0 --> 25.1.dev0 pex 2.73.1 --> 2.76.1 python-multipart 0.0.20 --> 0.0.21 soupsieve 2.8 --> 2.8.1 urllib3 2.5.0 --> 2.6.2 == Added dependencies == cross-web 0.4.0Also had to re-generate pytest due to
packagingtest failure:Lockfile diff: 3rdparty/python/pytest.lock [pytest] == Upgraded dependencies == asttokens 3.0.0 --> 3.0.1 coverage 7.10.7 --> 7.13.1 execnet 2.1.1 --> 2.1.2 iniconfig 2.1.0 --> 2.3.0 ipython 9.6.0 --> 9.8.0 matplotlib-inline 0.1.7 --> 0.2.1 packaging 25.0 --> 25.1.dev0