Depend directly on serde_derive #130
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Outside of tests, the only use of serde_derive is in schema.rs, which is only exposed when postcard's experimental-derive feature is enabled.
✅ Deploy Preview for cute-starship-2d9c9b canceled.
|
jamesmunns
added
the
postcard-2.0
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since serde v1.0.186, this is possible without risking errors from Cargo picking incompatible versions of
serdeandserde_derive. The benefit of not enabling serde's "derive" feature is that (non-incremental) builds can become a bit faster, as serde itself (and some things depending on it) can be compiled in parallel to proc-macro2, syn, andserde_derive. See serde-rs/serde#2584 for more discussion and background. In a project of mine where all transitive dependencies except postcard have already made the switch, this patch makes a clean build 3-4 seconds faster (out of a minute in total) on my machine.The downside of this change, besides the additional
uselines, is that it's easy to accidentally write code that breaks when used in a project where something else enables serde's "derive" feature. In scopes where the derive macros are imported fromserde_derive, importing the traits asserde::{Derive, Serialize}seems to work until it doesn't (see serde-rs/serde#1441). I think avoided that problem in this PR, but there's no good way to test it other than occasionally editing Cargo.toml to re-enable serde's "derive" feature. I'm honestly not sure if I'd want to deal with that as a library maintainer, no hard feelings if you don't want to either.The second commit goes one step further and makes postcard's
serde_derivedependency completely optional except as a dev-dependency, since it only seems to be needed for tests and for postcard-derive-related code in schema.rs. This is less impactful since virtually every crate depending on postcard also needsserde_deriveanyway, but it shouldn't hurt either and doesn't make things any more complicated than the first commit.This is a breaking change: projects using postcard are likely to depend on serde re-exporting the derive macros, and for some of them, postcard will be the only thing enabling serde's "derive" feature. But since a 2.0 release is likely coming anyway, I wanted to pitch this change.