summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Silverstone <dsilvers@digital-scurf.org>2019-11-25 22:01:09 +0000
committerDaniel Silverstone <dsilvers@digital-scurf.org>2019-11-25 22:01:09 +0000
commitde7c080cbbddd53dcc9797c38cdbaef27ecac428 (patch)
tree2d7a5f3be8b08e2d92ae85055c2052ffbaf7cc2e
parent69a62470c311dcb9068c4fa9ac4cc54ddc50764b (diff)
downloadblog-de7c080cbbddd53dcc9797c38cdbaef27ecac428.tar.bz2
Fix links a bit
-rw-r--r--posts/rust-2020.mdwn18
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