use aggressive forking when encountering markers #5733

Closes #4732

Previously, since the markers weren't disjoint, this didn't result in a fork. But now that we deal with overlapping markers, this is fine. And seems correct.

…rker The test in this case has this comment: ``` /// If a dependency requests a prerelease version with an overlapping marker expression, /// we should prefer the prerelease version in both forks. ``` With this setup: ``` let pyproject_toml = context.temp_dir.child("pyproject.toml"); pyproject_toml.write_str(indoc! {r#" [project] name = "example" version = "0.0.0" dependencies = [ "cffi >= 1.17.0rc1 ; os_name == 'Linux'" ] requires-python = ">=3.11" "#})?; let requirements_in = context.temp_dir.child("requirements.in"); requirements_in.write_str(indoc! {" cffi . "})?; ``` The change in this commit _seems_ more correct that what we had, although it does seem to contradict the comment. Namely, in the `os_name != "Linux"` fork, we don't prefer the pre-release version since the `cffi >= 1.17.0rc1` bound doesn't apply. It's not quite clear what to do in this instance.

Fixes #4668

Fixes #4640

…dn't! I wasn't expecting these scenarios to suddenly work, but because of the aggressive forking strategy of overlapping markers, these both now produce a valid resolution. Previously, we *only* forked when there were disjoint markers for the same dependency specification. But now we potentially fork whenever there is any single marker, and this results in different forks reaching what were conflicting dependency specifications. And thus, things work here.

From looking at this carefully, I believe the result here is still correct but "different" from the status quo based on the order in which forks are processed. (At time of writing, we do sort forks, but we don't use comprehensive criteria. So at least in some cases, the order depends on the order that the forks were created. Since the overlapping markers code completely changes how we generate forks, that seems plausible here.)

This is an interesting update that previously used a message without a fork occurring, but now notes a split. The dependencies in this case are: dependencies = [ '''fork-marker-disjoint-a>=2; sys_platform == "linux"''', '''fork-marker-disjoint-a<2; sys_platform == "linux"''', ] In this case, the markers are the same for conflicting dependency specifications. So the "no resolution" result is correct. But previously, we wouldn't fork here, because we wouldn't consider the marker expressions to be disjoint. But with overlapping markers, we are actually forking here. Namely, we consider a fork with `sys_platform == "linux"` and another with `sys_platform != "linux"`. I actually don't think this is even related to overlapping markers. The previous behavior seems not quite right (even though it led to the same result), because it implies we weren't really considering the "linux" and "not linux" cases as distinct in resolution.

This comes from this dependency specification: dependencies = ["requests", "requests[socks] ; python_version < '3.10'"] Previously, the `pysocks` dependency was unconditionally included when the `socks` extra was enabled. But it should only be included when `python_version < '3.10'`, which is now reflected here via a marker.

This commit is meant to group together test updates that are "uninteresting." That is, most updates are just adding marker expressions that are "always true" or establishing the forks in the lock file. I've tried to split out the interesting snapshot changes into subsequent commits. Some of the marker changes here are quite striking. I checked most of them. Every one I checked, including the big ones, are all just fancy ways of saying, "always true."

These changes all look wrong and would need to be resolved before merging.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

use aggressive forking when encountering markers #5733

use aggressive forking when encountering markers #5733

Commits on Aug 9, 2024