refactor(derive): drop tokio dependency #19
Conversation
|
Hey @fasterthanlime thanks for the recommendation and PR -- greatly enjoy your reading/watching your adventures. Change looks good to me, would you mind changing your PR comment to match a conventional commit (as we believe in them). Something like: The release tooling does pick this up and actually use it :) [EDIT] Oh BTW if you'd like me to make this change, please click the little "Allow edits by maintainers" checkbox and I will! |
fasterthanlime
changed the title
I haven’t seen this checkbox in a while and… here’s why: https://github.com/orgs/community/discussions/5634 I’ll stop making contributions from orgs I guess! |
|
TIL Hey @fasterthanlime actually I should have been clearer -- the commit is actually what matters :) Something like: (this repo disallows merge commits in general -- only fast-forward merges +/- rebase, so I try to keep the commit history perfectly conventional) |
The references to 'tokio' in `async-dropper-derive` are in quoted code, that crate is a proc macro that doesn't need tokio to run (ie. to manipulate token streams). Leaving it in as a dependency just means tokio would show up twice in the dep graph, built once for `async-dropper-derive` (as a proc macro dependency and unused), and once as a regular dependency. Having it as a dependency of `async-dropper-derive` also doesn't force users of the `derive` feature to have a dependency on tokio: they can still have compile errors due to the `tokio` symbol not being found if they don't _also_ depend on tokio in their crate, just like how <https://docs.rs/tracing-test/latest/tracing_test/> cannot force your crate to depend on `tracing` (even though its macro expansion needs it).
fasterthanlime
force-pushed
the
no-tokio-dep-for-derive
branch
from
0200717 to
203f328
Compare
Yup yup, am aware, I was just away from a computer x) amending/force-pushing is more than I'm willing to do from a phone. Should be good now! Interestingly the repo settings are so conservative that they need your approval again to run a second time. |
|
Ah I think once your contribution goes through you won't have to worry about approvals -- thanks again! |
The references to 'tokio' in
async-dropper-deriveare in quoted code, that crate is a proc macro that doesn't need tokio to run (ie. to manipulate token streams).Leaving it in as a dependency just means tokio would show up twice in the dep graph, built once for
async-dropper-derive(as a proc macro dependency and unused), and once as a regular dependency.Having it as a dependency of
async-dropper-derivealso doesn't force users of thederivefeature to have a dependency on tokio: they can still have compile errors due to thetokiosymbol not being found if they don't also depend on tokio in their crate, just like how https://docs.rs/tracing-test/latest/tracing_test/ cannot force your crate to depend ontracing(even though its macro expansion needs it).