On "Disabling Scheduled Dependency Updates"

I haven’t written any blogs on books or readings, so here’s what I’m gonna try: I will recommend some articles, and then write some comments about them.

This is the first piece of this series.


Recently, I read an article on dependency updates and I’d like to comment on it. Read the original article here. Or, here’s a summary for those TL;DR guys:

David Lord maintains numerous GitHub libraries, many of which are stable and require infrequent updates. He found that automated dependency update PRs from Dependabot and pre-commit.ci (3 PRs per project per month) created excessive notification noise and busywork, especially on the first of each month. This made it difficult to identify important notifications and gave a false impression of project activity. While automated updates are useful for applications, libraries don’t require this constant attention. To address this, he disabled automatic updates and created a local update command using pip-compile, pre-commit, and a custom tool called gha-update (for GitHub Actions). This allows him to update dependencies manually when actively working on a project, ensuring a working environment with pinned dependencies and the ability to update when needed. He uses tox to manage these update commands and all-repos to apply them across projects, giving him control over the update schedule.

I have three things to say, or maybe four:

  • What’s good about this article?
  • A refutation of the author’s arguments.
  • A very minor detail in this blog that isn’t critical to the subject.
  • And some of my random thoughts.

First things first, I disagree with some of his ideas.

But there are also a lot of things right. It can’t be all wrong; there is certain merit in everything, nothing can be completely wrong, right?

So, here’s what’s good about it: For a unified developer experience, pining and updating is the right thing to do.

If you specify a range for the dependency versions, like greater than some number, it’s by definition unpredictable and more susceptible to supply chain attacks. If you are interested in supply chain attacks and dependency confusion attacks, read my previous blogs:


The author wants to run dependency upgrades on his schedule, for three reasons, which are not valid in my opinion:

  • He mentioned 3 PRs per month per repo which has some overhead because of scrolling and clicking, but this can be mitigated by merging automatically. And, maybe you don’t have to do it monthly, more on this later.
  • He owns 20 repos, which is an extreme case. Just because you have 20 repos and can’t maintain them doesn’t necessarily mean everyone should update their dependencies manually even for just a single repo, right? This logic doesn’t stand.
  • Automation beats manual, there is no human error, no operational overhead, and so on. So I don’t think his arguments stand.

Third, I want to mention some minor details:

“For an application, especially with continuous deployments set up, scheduled updates probably make sense. You want to deploy with any bug fixes or security fixes as soon as possible.”

“For libraries, these dependencies are only running locally, as development environments. While new fixes and features are nice, they don’t need immediate, constant attention.”

I disagree, mostly on the first part.

Even for apps with continuous deployment setup, you probably shouldn’t always upgrade to the latest version ASAP. Yes, I do have a blog on this topic from a long time ago.

Most bugs and security issues appear in the first few months of the lifecycle of a software and after that, the bug numbers decrease drastically. That’s why Firefox, Chrome, and essentially all important software have enterprise support releases which lag months if not years behind standard releases. You should not always upgrade to the latest version, a monthly upgrade is probably too much, I’d do a 3-monthly update maybe.


Last, I want to share an idea from recent years of reading: writers should be more responsible about how they might change readers’ opinions or even lives. I’ll give you two examples:

If you want to do something manual, it’s ok, it’s YOUR choice, and that’s fine.

I do a lot of things manually: I like changing gears myself, no matter on my bike or in my car; oftentimes I’m too lazy to use regex to match all certain patterns in a text file, so I just select one and hold Command+D for a while in Sublime Text to do the same. I have the time, I can wait for “a while”.

However (and this is a big “however”), I don’t recommend you to do the same. That’s just me, alright? I certainly wouldn’t go so far as to write a blog about how manual I am. Just because I can write about my preferences doesn’t mean I should, because it’s a personal choice that doesn’t fit all (or rather, fits only a very small crowd of audience). I don’t want to write about something that is essentially only a personal preference and is by and large “incorrect”.

However (and this is also a big “however”), as a core developer of Flask who is relatively famous and has a certain impact circle that isn’t negligible (I mean the author of the article), you should probably be a little bit more responsible to your audience and communities, you should know most people don’t maintain 20 repos and update dependencies 3 pull requests per repo per month, and you should definitely NOT blog about manually doing stuff that only works for you in your specific case. Inexperienced readers might think “your way” is the way to go no matter what — if it’s the best choice for a core Flask developer, it’s good enough for me, right?

Let me give you another example.

I like a Japanese reader called Murakami Haruki, he has a book named “Killing Commendatore” which I enjoyed quite much and read twice.

The main character of the book is a rich guy, who lives in a big lonely house in the mountains, drives a Jaguar, can’t sleep at night, wakes up at 2 am every day, pours himself malt beverage, and eats some cashews.

Many of his books are like that, he writes a lot of details, but after reading too many of his books, you might start to think that drinking whiskey and eating cashews as a snack is good because if that’s what a rich guy who drives a tasteful car that Murakami Haruki thinks should do, it’s probably very tasteful and I shall have some of that, right?


We form our opinions in the world, what we see and read matters because, to a certain extent, they help shape our worldview.

On that note, I’d like to wrap up with a notice to all writers: Stop writing stuff that’s only appealing to you and start being just a little bit more responsible. Because why not?

comments powered by Disqus
Built with Hugo
Theme Stack designed by Jimmy