search

bkchr / proc-macro-crate

`$crate` in procedural macros.
Apache License 2.0
65 stars 17 forks source link

Why Pin Dependency Versions? #44

Closed westy92 closed 10 months ago

westy92 commented 11 months ago

I'm curious, why did you pin dependency versions instead of allowing updates to be used?

[dependencies]
toml_edit = "=0.20.2"
toml_datetime = "=0.6.3"

For example, toml_edit's latest version is 0.21.0, or 0.20.7 on the 0.20.x line. Likewise, 0.6.5 is the latest version of toml_datetime.

Upgrading proc-macro-crate just caused some of my dependencies to downgrade.

bkchr commented 11 months ago

Hey, because the new version of toml_edit and toml_datetime are requiring a newer minimal rustc version and this would require a major version bump of this crate.

kayabaNerve commented 11 months ago

Shouldn't the users who need a minimal rustc version vendor a lockfile which resolves this? I don't see why this crate should be so opinionated as it's effectively taking the role of the lockfile despite being a library, not a lockfile.

To be clear, I do get not updating to versions exclusive to new rustc versions. I don't get pinning to specific patch versions.

bkchr commented 11 months ago

There are some people who say that breaking MSRV requires a bump of the major version. Quite controversial topic, but I would follow this for now. I will hopefully in the short term write my own small toml parser to not require to pin the dependency.

kayabaNerve commented 11 months ago

I don't inherently disagree with the MSRV commentary. I was disagreeing that supporting a toml range which has options which breaks MSRV means proc-macro-crate is itself breaking MSRV, so long as the range has options which don't break MSRV. Of course, it's up to you, and I don't want to push the issue.

I do appreciate the planned migration which would remove the pin :)

ilya-bobyr commented 11 months ago

We use borsh which depends on proc-macro-crate. After we upgrade our borsh to 1.2.1 our dependency graph is now broken. We have another dependency on a crate that depends on toml version 0.8.8. And toml 0.8.8 depends on toml_datetime 0.6.5.

A dependency on 0.6.5 actually means that >=0.6.5. And an explicit =0.6.3 is incompatible with that.

cargo does not allow two versions of the same library that are different only in the patch version. And so our project just does not compile with a newer borsh.

My understanding is that libraries should never use =X.Y version requirements. It will create "breakage at a distance" that is impossible for your users to fix. There is literally nothing we can do, except to fork this crate and remove the =X.Y version constraint, if we want a newer borsh. We actually did it for two packages that are not maintained anymore. As they block us from keeping our dependencies up to date.

I am pretty sure you did not want to block your users from moving to a newer borsh version :)

ilya-bobyr commented 10 months ago

Any chance #45 could be merged into the next release?