-
Notifications
You must be signed in to change notification settings - Fork 751
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
Update to packse 0.3.31 #5441
Update to packse 0.3.31 #5441
Conversation
/// Like `preferences-dependent-forking`, but when we don't fork the resolution | ||
/// fails. Consider a fresh run without preferences: * We start with cleaver 2 * We | ||
/// fork * We reject cleaver 2 * We find cleaver solution in fork 1 with foo 2 with | ||
/// bar 1 * We find cleaver solution in fork 2 with foo 1 with bar 2 * We write | ||
/// cleaver 1, foo 1, foo 2, bar 1 and bar 2 to the lockfile In a subsequent run, | ||
/// we read the preference cleaver 1 from the lockfile (the preferences for foo and | ||
/// bar don't matter): * We start with cleaver 1 * We're in universal mode, cleaver | ||
/// requires foo 1, bar 1 * foo 1 requires bar 2, conflict Design sketch: ```text | ||
/// root -> clear, foo, bar # Cause a fork, then forget that version. cleaver 2 -> | ||
/// unrelated-dep==1; fork==1 cleaver 2 -> unrelated-dep==2; fork==2 cleaver 2 -> | ||
/// reject-cleaver-2 # Allow different versions when forking, but force foo 1, bar 1 | ||
/// in universal mode without forking. cleaver 1 -> foo==1; fork==1 cleaver 1 -> | ||
/// bar==1; fork==2 # When we selected foo 1, bar 1 in universal mode for cleaver, | ||
/// this causes a conflict, otherwise we select bar 2. foo 1 -> bar==2 ``` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@zanieb Should it be collapsing the markdown?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems less than ideal. It seems fine to leave it on multiple lines? I'm not sure why this is happening.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
537f206
to
835f16a
Compare
Unlike json scenarios, toml and yaml scenarios have multi-line description fields, in which we can write proper markdown. Textwrap doesn't understand markdown and mangles it. To fix astral-sh/uv#5441 (comment), we stop textwrapping toml and yaml files. I've tested this locally and the snapshots look better, due to astral-sh/uv#5475 is somewhat incomplete though: astral-sh/uv#5441.
835f16a
to
ff6d3ec
Compare
ff6d3ec
to
68d5d05
Compare
I'm going ahead with this to unblock using these tests for #5180. We can fix the comments in a later update. |
Unlike json scenarios, toml and yaml scenarios have multi-line description fields, in which we can write proper markdown. Textwrap doesn't understand markdown and mangles it. To fix astral-sh/uv#5441 (comment), we stop textwrapping toml and yaml files. I've tested this locally and the snapshots look better, due to astral-sh/uv#5475 is somewhat incomplete though: astral-sh/uv#5441.
Unlike json scenarios, toml and yaml scenarios have multi-line description fields, in which we can write proper markdown. Textwrap doesn't understand markdown and mangles it. To fix astral-sh/uv#5441 (comment), we stop textwrapping toml and yaml files. I've tested this locally and the snapshots look better, due to astral-sh/uv#5475 is somewhat incomplete though: astral-sh/uv#5441.
Update packse to 0.3.31, adding the instability scenarios.