-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Support workspace-level crate version denylist / local yanking #13856
Comments
You currently also have other options:
Are those solutions good enough for you? |
Thanks for the report. I love the amount of details you filled in! I wonder if we could consolidate similar feature requests into one location, so people don't need to jump between issues to get the full picture. Personally I favor #5286 and close this. Does that sound good to you? |
@weihanglo @mladedav |
4th comment in #5286:
I appreciate it's not the issue itself, but this seems to exactly describe what you're proposing here? |
I see, yes this comment matches the goal of the issue here; but then @epage replies that the global denylist is not the goal of #5286 so I find it a bit confusing. When searching for existing issues I saw this one, and their comment is actually why I opened a dedicated issue for this feature. Anyway, if you think that it's clear enough if this issue is closed/it's better for triage then it's fine for me. 👍 |
While I focused on the implementation in my discussion for #5286, I think the most important thing is to focus on the underlying requirements and to allow discussion of multiple solutions for the underlying requirements in one place to avoid fracturing the discussion. However, I think the solutions discussed in each are tightly related to the underlying problem in each which are distinct. In #5296 the concern is with the published result of a package (in this issue's terms, from the perspective of the publisher of This issue is about the generation of The user and who they are trying to help in each story is different. |
Problem
Occasionally, crates release a semver-violating version that causes breakage when consumed.
Cargo currently has two main features to address this issue:
The first approach is the best one, but it requires active intervention of the crate authors which may sometime take a few days. The second approach works great if the dependency was already used through a good version, however it's not easy to use when we want start using this dependency. This dependency can be deep in the chain so applying requirements locally in the workspace may not work. There are also solutions involving forking the crate or pointing to some other source (such as the Git repo), but these feel more complex than needed since the working version already exists in the registry, cargo resolution should be able to resolve it.
The scenario is the following:
foo
has a private dependency onclumsy ^1.0.0
bar
has a private dependency onclumsy ^2.0.0
myproject
depends onfoo
onlyclumsy
releases2.0.1
which contains a semver violationmyproject
wants to add a dependency onbar
, but by doing so cargo pulls the brokenclumsy 2.0.1
instead of the workingclumsy 2.0.0
myproject
now needs to wait for an upstream fix or manually edit the lock file to addfoo
andclumsy 2.0.0
, which is pretty tedious.Proposed Solution
The solution for me would be to help resolution / updating the lock file in presence of semver violations without expecting coordination from third-party libraries, In the problem description, the fix could also be applied in
bar
, but in all casesmyproject
has to wait for a fix upstream instead of fixing it itself locally and moving on. I expect the solution to be applied locally at the workspace level and not be used when publishing the top crate to the registry.The restricted solution for this issue of semver violations would be to have a way to mark at the workspace level that a crate version should be treated as yanked. When cargo performs resolution, a crate version is treated as yanked if it is marked as such either on the registry or in the workspace manifest (for example in the patch section). Resolution proceeds with regular yanking semantics. With this solution,
myproject
would flag[email protected]
as yanked and cargo resolution would select[email protected]
.A more general solution would be to allow patching dependency requirements.
myproject
could patchbar
to depend onclumsy =2.0.0
instead ofclumsy ^2.0.0
.Another general solution would be support for version substitution when patching the registry. Right now
patch.crates-io.clumsy
can swap it to apath
orgit
dependency, but it could also support swapping for a different version from the registry.Notes
Despite being currently affected by the scenario above, I prefer to avoid sharing exact details of the crates involved as general improvements to occasional semver violations feel more important than blaming specific instances which should be fixed eventually anyway. It's not the first time that I encounter a semver violation, nor the last and it would be nice to have an escape hatch. EDIT: The violation that prompted me to fill this issue was fixed through yanking after 3 days.
Also related:
The text was updated successfully, but these errors were encountered: