diff options
| author | Daniel Silverstone <dsilvers@digital-scurf.org> | 2019-11-25 22:01:09 +0000 |
|---|---|---|
| committer | Daniel Silverstone <dsilvers@digital-scurf.org> | 2019-11-25 22:01:09 +0000 |
| commit | de7c080cbbddd53dcc9797c38cdbaef27ecac428 (patch) | |
| tree | 2d7a5f3be8b08e2d92ae85055c2052ffbaf7cc2e | |
| parent | 69a62470c311dcb9068c4fa9ac4cc54ddc50764b (diff) | |
| download | blog-de7c080cbbddd53dcc9797c38cdbaef27ecac428.tar.bz2 | |
Fix links a bit
| -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 |