diff options
| -rw-r--r-- | posts/rust-2020.mdwn | 18 |
1 files changed, 9 insertions, 9 deletions
diff --git a/posts/rust-2020.mdwn b/posts/rust-2020.mdwn index 2e8a37e..21818af 100644 --- a/posts/rust-2020.mdwn +++ b/posts/rust-2020.mdwn @@ -130,12 +130,12 @@ part this is because the community is so confident with the semantic versioning we all take care of, but also because there's an amount of release anxiety manifesting. What's *worse* than this though is the way that we end up with sets of incompatible dependency chains on many of these "primary" crates. It -is not uncommon to end up with multiple version of [`rand`][], [`syn`][], -[`quote`][], or others in your dependency tree. Not all of that is the fault -of the authors of those libraries either, but because other crates are not yet -up-to-date with changes in them. For example, `syn` is already in its `1.0` -series and yet via various pathways, `rustup` ends up depending on `0.15` as -well. +is not uncommon to end up with multiple version of [`rand`][rand], +[`syn`][syn], [`quote`][quote], or others in your dependency tree. Not all of +that is the fault of the authors of those libraries either, but because other +crates are not yet up-to-date with changes in them. For example, `syn` is +already in its `1.0` series and yet via various pathways, `rustup` ends up +depending on `0.15` as well. In order to be more includible into distributions such as Debian, it's critical that the Rust community as a whole looks to address this kind of thing. It @@ -143,9 +143,9 @@ seems odd to say that "gardening" your library's dependencies can be a way to lead to being more includible into other things, to enhance "inclusivity" as I'm choosing to define it for this post, but it is indeed one pathway. -[`rand`]: https://crates.io/crates/rand -[`syn`]: https://crates.io/crates/syn -[`quote`]: https://crates.io/crates/quote +[rand]: https://crates.io/crates/rand +[syn]: https://crates.io/crates/syn +[quote]: https://crates.io/crates/quote An end-goal of this is that a majority of tools ought to be buildable with a unified *singular* set of library crate versions if they are going to be |