To expand, there are two reasons for minimal-direct
- (original, unrelated reason) a practical way to move forward in testing minimum version requirements without being blocked on your transitive dependencies like with
minimal
- So a library author can run
cargo upgrade --save
without upgrading compatible version requirements while still getting the benefits of all of their transitive dependencies being updated- Thinking more about this, they are unlikely to care about using minimal versions for
dev-dependencies
and would want the latest MSRV compatible version for those. Unsure how best to balance that
- Thinking more about this, they are unlikely to care about using minimal versions for
Current temperature is that version resolution should stay unaware by default (but print a warning suggesting updating toolchains or downdating)
Maybe I missed a thread but I've seen one or two people say it should be unaware by default. I think its premature to say to convey that that is a consensus so far.
Does
cargo update -p --precise
(already?) allow changing major versions? Downgrading?
Upgrading across major versions errors about being incompatible with the version req. Similarly downgrading must satisfy the existing version req.
Can we reuse
--precise
such that--save --precise
gets me full-precision dependencies?
That would be conflating two unrelated things with the flag.
I am still not in favor of editing precision. For others to catch up, see my comment
What is
--save --locked
? Is the manifest locked (causing an error; perhaps better spelled--verify
), or is only the lockfile locked (givingupgrade --to-lockfile
)?
This is the unfortunate part, cargo update --locked
errors if a lockfile update would happen.
As mentioned earlier, I see a minimal-direct
resolver replacing today's cargo upgrade --to-lockfile
.
How is a "pinned" dependency defined? ... Consider VersionReq which are not a single (implicit) caret operator to be pinned.
As of today, it is
- Renamed dependency (assuming the
tokio_01
case) - An upper bound was placed on the dependency besides
^
(e.g.=
)
For expanding the definition to all non ^
operators, how is >
pinning?
Does
cargo update
without any of the other new flags change behavior on--pinned
?
--pinned
opts you into modifying pinned dependencies. Since cargo update
updates compatible pinned dependencies today, we can't change that. That means --pinned
is restricted to only --incompatible
upgrades.
Does
--pinned --incompatible
opt into updating outside of the pinned region but within the same major version, or does it allow upgrading across different major versions?
We upgrade to latest, whatever that is, like all other --incompatible
changes.
When
--pinned
's upper bound is changed, what form does it take?
I believe we keep the same upper bound operator
Consider (actually[^1]) renamed dependencies as pinned.
Can you give a concrete example of how the "actually" case is different than the current behavior?
With
--pinned
without--incompatible
- Update pinned dependencies as-if their top bound was a caret.
I worry about being able to clearly communicate the different versions of --pinned
to the user and would prefer just one meaning.