Skip to content
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

Determine whether it's acceptable to remain pinned to a particular version of syn, or choose a different workaround #1088

Closed
2 tasks
Tracked by #671
joshlf opened this issue Apr 2, 2024 · 2 comments
Labels
blocking-next-release This issue should be resolved before we release on crates.io

Comments

@joshlf
Copy link
Member

joshlf commented Apr 2, 2024

To work around #1085 until we have a more complete solution, we plan to pin our dependency on syn to a specific version (#1089). We need to remove this workaround and implement a more complete solution before releasing 0.8.

Progress

  • Determine whether continuing to remain pinned to a particular version of syn will be problematic for 0.8; consider both dependency resolution and build-time performance
    • An alternative: could we pin to a particular version only on certain Rust toolchains, but leave it unpinned for more recent toolchains? We would need to consider whether we run the risk of future MSRV bumps, or whether we can structure the dependency in such a way that it just always works. This would resolve the build-time performance issues for most users.
  • If we decide not to continue pinning, consider this workaround:
    • Declare that zerocopy-derive's MSRV is just whatever syn's is (TODO: How do we pin this in CI for testing?)
    • Document that zerocopy's derive feature is exempt from our MSRV
    • After 0.8, work to resolve this - in the most optimistic scenario, we can return to having both crates have the same MSRV, but at least we won't be blocked on it
@joshlf joshlf mentioned this issue Apr 2, 2024
87 tasks
joshlf added a commit that referenced this issue Apr 2, 2024
This is a temporary work-around for #1085. Per #1088, we will remove
this and implement a more complete fix before releasing 0.8 (#671).
joshlf added a commit that referenced this issue Apr 2, 2024
This is a temporary work-around for #1085. Per #1088, we will remove
this and implement a more complete fix before releasing 0.8 (#671).
github-merge-queue bot pushed a commit that referenced this issue Apr 2, 2024
This is a temporary work-around for #1085. Per #1088, we will remove
this and implement a more complete fix before releasing 0.8 (#671).
@joshlf joshlf added the blocking-next-release This issue should be resolved before we release on crates.io label May 30, 2024
@joshlf joshlf changed the title Un-pin dependency on specific version of syn Determine whether it's acceptable to remain pinned to a particular version of syn, or choose a different workaround May 30, 2024
@joshlf
Copy link
Member Author

joshlf commented Jun 25, 2024

Bad news. Investigated this locally and it looks like it can cause problems:

$ ls -R
downstream      zerocopy-derive

./downstream:
Cargo.toml src

./downstream/src:
lib.rs

./zerocopy-derive:
Cargo.toml src

./zerocopy-derive/src:
lib.rs

$ cat downstream/Cargo.toml
[package]
name = "downstream"
version = "0.1.0"
edition = "2021"

[dependencies]
syn = "=2.0.54"
zerocopy-derive = { path = "../zerocopy-derive" }

$ cat zerocopy-derive/Cargo.toml
[package]
name = "zerocopy-derive"
version = "0.1.0"
edition = "2021"

[dependencies]
syn = "=2.0.55"

$ cd downstream && cargo check
    Updating crates.io index
error: failed to select a version for `syn`.
    ... required by package `zerocopy-derive v0.1.0 (.../zerocopy-derive)`
    ... which satisfies path dependency `zerocopy-derive` of package `downstream v0.1.0 (.../downstream)`
versions that meet the requirements `=2.0.55` are: 2.0.55

all possible versions conflict with previously selected packages.

  previously selected package `syn v2.0.54`
    ... which satisfies dependency `syn = "=2.0.54"` of package `downstream v0.1.0 (.../downstream)`

failed to select a version for `syn` which could resolve this conflict

@joshlf
Copy link
Member Author

joshlf commented Jul 2, 2024

Discussed with @jswrenn and @djkoloski and decided that this isn't feasible.

@joshlf joshlf closed this as completed Jul 2, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocking-next-release This issue should be resolved before we release on crates.io
Projects
None yet
Development

No branches or pull requests

1 participant