Update optional parking_lot dependency to 0.11.0

[jbg]

Motivation

Part of a long-running quest to minimise binary size bloat in our projects by eliminating duplicate dependencies (dependencies with more than one version compiled in).

Solution

Update the optional parking_lot dependency in tokio to version 0.11.0. The MSRV is unchanged from 0.10.0, and parking_lot's API changes in 0.11.0 do not affect tokio.

[hawkw]

What do you think about a more permissive requirement that allows both, like

Suggested change

	parking_lot = { version = "0.11.0", optional = true } # Not in full
	parking_lot = { version = ">= 0.10.0, <= 0.11.0", optional = true } # Not in full

If the goal is just to reduce duplicate dependency versions, this would be the ideal choice --- if other dependencies in tree are already pulling 0.10, Cargo would select that version. Tokio doesn't really use any of the APIs that have changed between those releases...

[Darksonn]

Would that prevent using 0.11.1 once that is released?

[carllerche]

What would be the advantage? Seems best to track deps?

[hawkw]

Would that prevent using 0.11.1 once that is released?

Err, I meant < 0.12.0.

What would be the advantage? Seems best to track deps?

The idea is that Tokio should be able to use whatever parking_lot version is pulled in by another crate, if there is one in-tree, to minimize compiling duplicate versions. If another crate has an older dependency, we could just use it, and prefer the latest if no other crate depends on some other version.

I'm not sure if this is the right choice or not, but the only parking_lot APIs we depend on are the ones that mimic std, and therefore will probably not change very much. We can ignore breaking changes to unrelated APIs that we don't care about in order to reduce the total number of parking_lots in a crate where multiple dependencies use parking_lot.

This is a loosely-held opinion...I'm willing to be convinced this is a bad idea.

[carllerche]

I don't have any data on whether or not it works well. If you think it is worth it, we can try it. I also do not know if the cargo dependency resolver is smart enough to dedup the way you are describing (it is a very hard problem).

[Darksonn]

I recall having heard issues with the resolver in cases like this before on the user's forum. I would want to test that it really works properly before doing this.

[hawkw]

Hmm, not a big deal if this doesn't work, then!

[jebrosen]

Unless something changed within the last ~year, cargo will prefer using the latest versions possible for everything even if deduplication would be possible, unless the crate being deduplicated uses links (out of necessity) - see also rust-lang/cargo#4902 (comment).

[dekellum]

Forgive the late comment on this, but since the merged change its not released yet...

Besides this optional parking_lot tokio feature, I have two other deps that depend on parking_lot, and one of them tends to be slow to update. The change as merged (084fcd7) will ensure that there are duplicate parking_lot versions until the other deps upgrade.

The alternative that @hawkw proposed above (">=0.10.0, <0.12") would make it possible to avoid the duplicate. What @jebrosen states above matches my experience: cargo will prefer to use latest version over minimizing duplicates. But with the more permissive range its possible to selectively update or manually downgrade in the lock file to avoid the duplicate. Once all my deps permit parking_lot 0.11.0, I can then upgrade without a duplicate and without further change in tokio.

Are you willing to reconsider?