about summary refs log tree commit diff homepage
path: root/blog/2020/gsoc/article
diff options
context:
space:
mode:
Diffstat (limited to 'blog/2020/gsoc/article')
-rw-r--r--blog/2020/gsoc/article/1.md2
-rw-r--r--blog/2020/gsoc/article/3.md4
-rw-r--r--blog/2020/gsoc/article/4.md6
-rw-r--r--blog/2020/gsoc/article/5.md2
-rw-r--r--blog/2020/gsoc/article/7.md4
5 files changed, 9 insertions, 9 deletions
diff --git a/blog/2020/gsoc/article/1.md b/blog/2020/gsoc/article/1.md
index b0e6a7b..b98e2d5 100644
--- a/blog/2020/gsoc/article/1.md
+++ b/blog/2020/gsoc/article/1.md
@@ -69,7 +69,7 @@ the resolution of dependency.  While this is only applicable to wheels
 (i.e. prebuilt packages), other packaging format only make up less than 20%
 of the downloads (at least on PyPI), and the figure is much less for
 the most popular packages.  Therefore, this optimization alone could make
-[the upcoming backtracking resolver][]'s performance par with the legacy one.
+[the upcoming backtracking resolver]'s performance par with the legacy one.
 
 During the last few years, there has been a lot of effort being poured into
 replacing `pip`'s current resolver that is unable to resolve conflicts.
diff --git a/blog/2020/gsoc/article/3.md b/blog/2020/gsoc/article/3.md
index 9c41b31..175486c 100644
--- a/blog/2020/gsoc/article/3.md
+++ b/blog/2020/gsoc/article/3.md
@@ -15,8 +15,8 @@ and group projects left to be done.  I for sure underestimated the workload
 of these and in the last (and probably next) few days I'm drowning in work
 trying to meet my deadlines.
 
-One project that might be remotely relevant is [cheese-shop][], which tries to
-manage the metadata of packages from the real [Cheese Shop][].  Other than that,
+One project that might be remotely relevant is [cheese-shop], which tries to
+manage the metadata of packages from the real [Cheese Shop].  Other than that,
 schoolwork is draining a lot of my time and I can't remember the last time
 I came up with something new for my GSoC project )-;
 
diff --git a/blog/2020/gsoc/article/4.md b/blog/2020/gsoc/article/4.md
index 43738a7..5a1cf50 100644
--- a/blog/2020/gsoc/article/4.md
+++ b/blog/2020/gsoc/article/4.md
@@ -30,7 +30,7 @@ and rebased, but my `git` skill is far from gud enuff to confidently do it.
 
 Testing this one has been a lot of fun though.  At first, integration tests
 were added as a rerun of the tests for the new resolver, with an additional flag
-to use feature `fast-deps`.  It indeed made me feel guilty towards [Travis][],
+to use feature `fast-deps`.  It indeed made me feel guilty towards [Travis],
 who has to work around 30 minutes more every run. Per Chris Hunt's suggestion,
 in the new PR, I instead write a few functional tests for the area relating
 the most to the feature, namely `pip`'s subcommands `wheel`,
@@ -45,7 +45,7 @@ Why did I say I'm half way there?  With the parallel utilities merged and a way
 to quickly get the list of distribution to be downloaded being really close,
 what left is *only* to figure out a way to properly download them in parallel.
 With no distribution to be added during the download progress, the model of this
-will fit very well with the architecture in [my original proposal][].
+will fit very well with the architecture in [my original proposal].
 A batch downloader can be implemented to track the progress of each download
 and thus report them cleanly as e.g. progress bar or percentage. This is
 the part I am second-most excited about of my GSoC project this summer
@@ -71,7 +71,7 @@ the upcoming Pinephone prototype.  It's one of the first smartphones
 to fully support a GNU/Linux distribution, where one can run desktop apps
 (including proper terminals) as well as traditional services like SSH,
 HTTP server and IPFS node because why not?  Just a few hours ago,
-I pre-ordered the [postmarketOS community edition][] with additional hardware
+I pre-ordered the [postmarketOS community edition] with additional hardware
 for convergence.
 
 If you did not come here for a Pinephone ad, please take my apologies though d-;
diff --git a/blog/2020/gsoc/article/5.md b/blog/2020/gsoc/article/5.md
index de2ef8d..5404089 100644
--- a/blog/2020/gsoc/article/5.md
+++ b/blog/2020/gsoc/article/5.md
@@ -15,7 +15,7 @@ Last Wednesday, `pip` 20.2 was released, delivering the `2020-resolver`
 as well as many other improvements!  I was lucky to be able
 to get the `fast-deps` feature to be included as part of the release.
 A brief description of this *experimental* feature as well as testing
-instruction can be found on [Python Discuss][].
+instruction can be found on [Python Discuss].
 
 The public exposure of the feature also remind me of some further
 {{pip 8681 optimization}} to make on {{pip 8670 "the lazy wheel"}}.
diff --git a/blog/2020/gsoc/article/7.md b/blog/2020/gsoc/article/7.md
index 58d8d33..c574865 100644
--- a/blog/2020/gsoc/article/7.md
+++ b/blog/2020/gsoc/article/7.md
@@ -41,7 +41,7 @@ $ pip --use-feature=2020-resolver --use-feature=fast-deps \
    --no-cache-dir download {requirement}  # fast-deps
 ```
 
-In the first test, I used [axuy][] and obtained the following results
+In the first test, I used [axuy] and obtained the following results
 
 | legacy-resolver | 2020-resolver | fast-deps |
 | --------------- | ------------- | --------- |
@@ -71,7 +71,7 @@ which are apparently more expensive than actual data transmission on my network.
 
 ### Large Distribution
 
-In this test, I used [TensorFlow][] as the requirement and obtained
+In this test, I used [TensorFlow] as the requirement and obtained
 the following figures:
 
 | legacy-resolver | 2020-resolver | fast-deps |