I have a couple of inactive Pinax sites at different versions (0.9.x and 0.7.x). These both started with two common features:

  1. While the version of Pinax was the most recent to have a (nonempty) social starter project, they were both relatively old; and:

  2. Installation hinged on procuring some extremely rare and difficult dependencies.

In looking at this, there seems to be a theme of increasing fragility. Dependencies seem to constitute single points of failure, and the trend is to have more and more of them.

Any suggestions about how to cope with this, above creating a virtualenv while you still can? What options should I consider if I want minimize adding (possibly ephemeral) dependencies? Are there ways to estimate how ephemeral a given dependency is?

Possibly with enough duct tape, I might for instance have a gallery of virtualenvs, and ensure that every single version of every single dependency is available in source and installed format.

I'm looking at creating all of a self-contained project with its own "roll your own" apps, not because I think this is desirable or Pythonic in itself, but to quarantine most or all single points of failure to my own code, which ideally should be working and deployable after downloading Python, Django (if needed) and my project alone.

  • I might for instance have a gallery of virtualenvs, and ensure that every single version of every single dependency is available in source and installed format. -- This, if you can. It's the only way to guarantee availability of the dependencies you need. You don't necessarily need every single version of every dependency, but only those that pertain. Commented Jan 13, 2018 at 16:43

1 Answer 1


Dependency management involves risk management, which can be seen as an argument both for and against dependencies.

When I have a dependency, risks are that:

  • the dependency may become unavailable in the future (*cough* leftpad)
  • the dependency may evolve in incompatible ways
  • the dependency may turn out to be insufficiently flexible after I'm already locked in to using it
  • the dependency may contain bugs and vulnerabilities

Yet when I don't use a dependency and write my own code, risk are that:

  • I may spend disproportionate effort on a substitute
  • my code may contain more bugs because it's used less
  • my code may contain grave security issues because I'm less familiar with the problem domain and security concepts
  • my code may turn into technical debt over the years

Any kind of code is a liability, regardless of who writes it.

Many of the risks implied by using dependencies can be mitigated, depending on your package manager.

Availability and compatibility are fairly easy to ensure, by pinning a version or version range, and hosting your own copy. Every package manager allows you to to provide your own mirror for the packages that you use. This may be as simple as a local directory full of tarballs that can be backed up easily. There may also be tools that can bundle up pinned versions of all dependencies in an easily distributable archive. Other package managers may require you to host a server, which could make a mirror less attractive. Note that the mirror should be kept somewhat up to date in order to benefit from upstream security patches.

A “rare and difficult” dependency should not exist. If you can host a dependency yourself it's not rare, and if it can be installed via some package manager it's not difficult. If you depend on a service such as a database then that is more difficult because it not only needs to be installed, but also needs to be running. Specifying your setup with configuration management tools or by creating a container image could then be useful.

A note on installing from version control repositories, e.g. from GitHub: someone else's repository is not a wise dependency. Instead, always check out a specific revision, and always point to a fork under your control.

How paranoid you should be about dependencies depends on the nature of the project. For my open-source projects I don't apply any of these mitigation steps. Not worth it, beyond requiring some minimum version. For my professional work, I've come to value more controlled dependencies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.