Required Reading

(Pun absolutely intended. 👌)

  • Unless you’re already familiar with pip-tools, be sure to read Vincent Driessen’s article on Better Package Management.
  • After drinking the pip-tools kool-aid, read Kenneth Reitz’s article on A Better Pip Workflow™.
  • If by now you’re unconvinced that your project could benefit in terms of maintainability and build determinism by adding a separate requirements.txt for top-level dependencies, then what are you still doing here?

State of Python Package Management

Although new and improved ways of managing Python requirements are on the horizon, the current standard of including and maintaining at least one requirements.txt file probably isn’t going anywhere.

Third-party tools like pip-tools aren’t perfect solutions, but until an officially sanctioned alternative is implemented and released, Python package maintainers are going to have to decide the workflow that suits their needs.

The Case for Tooling

Some would argue that installing additional tools to manage package requirements adds unnecessary overhead to the development process. This argument certainly has merit, but it should be noted that pip itself was an external tool until it came installed with Python after version 2.7.9. And while Pipfile looks incredibly promising, it might be safe to assume that it wouldn’t be included in a Python distribution in the immediate future. Oh, and virtualenv remains an external tool, although it was included in the standard library through PEP 405 (Python 3.3+).

Whether or not extra tooling for managing a project’s requirements is necessary is up to the author(s), but historically, as well as in other spaces, managing software dependencies has frequently involved more than one tool.