third-party libraries

Third-party libraries can be quite useful, especially when they provide tools that the standard library doesn’t include or when they offer a more ergonomic API for a task you do often. At the same time, every dependency adds maintenance overhead and increases the chance of version conflicts.

For third-party packages, these best practices help you keep your dependency footprint healthy:

• Add third-party dependencies deliberately and sparingly: Treat each external dependency as a design decision, not a shortcut.
• Isolate dependencies per project: Install third-party packages in a virtual environment so different projects don’t fight over versions.
• Carefully evaluate packages before installing them: Check the project’s PyPI page, documentation, and repository. Look at supported Python versions, release history, and whether the project is actively maintained.
• Document and pin your dependencies: Record your dependencies in a dependency file and lock their versions as part of your project’s dependency management workflow.

To see why pinning dependencies matters, say that your project needs a couple of third-party packages:

🔴 Avoid this:

$ python -m pip install requests rich

This approach works, but it doesn’t document which versions you installed. That makes it harder to reproduce your environment later and easier to accidentally pick up breaking changes.

✅ Favor this:

requests~=2.32
rich~=15.0

$ python -m venv .venv
$ source .venv/bin/activate
(.venv) $ python -m pip install -r requirements.txt

Here, you document your third-party dependencies and constrain them to compatible versions. The ~= operator allows compatible releases, so it bounds a version range instead of fixing one version. Pinning goes further: it records exact == versions for every package, including the transitive ones you didn’t install directly, usually in a lock file that you generate with python -m pip freeze > requirements.txt or an equivalent tool. Either way, you make installs more repeatable and upgrades more deliberate.

Two standardized formats cover this ground beyond requirements.txt: packaged projects declare their dependencies in pyproject.toml under [project] (PEP 621), and exact resolved versions go in a pylock.toml lock file, standardized by PEP 751 in 2025 and produced by tools like uv and pip.

Related Resources

Tutorial

How to Evaluate the Quality of Python Packages

Just like you shouldn't download any file from the Internet, you shouldn't install third-party Python packages without evaluating them first. This tutorial will give you the tool set to evaluate the quality of external Python packages before you incorporate them into your Python projects.

intermediate best-practices

For additional information on related topics, take a look at the following resources:

• Python Virtual Environments: A Primer (Tutorial)
• Using Python's pip to Manage Your Projects' Dependencies (Tutorial)
• Dependency Management With Python Poetry (Tutorial)
• uv vs pip: Managing Python Packages and Dependencies (Tutorial)
• uv vs pip: Python Packaging and Dependency Management (Course)
• How to Publish an Open-Source Python Package to PyPI (Tutorial)
• The Python Rich Package: Unleash the Power of Console Text (Tutorial)
• Python's Requests Library (Guide) (Tutorial)
• Working With Python Virtual Environments (Course)
• Python Virtual Environments: A Primer (Quiz)
• A Beginner's Guide to pip (Course)
• Using Python's pip to Manage Your Projects' Dependencies (Quiz)
• Managing Dependencies With Python Poetry (Course)
• Dependency Management With Python Poetry (Quiz)
• uv vs pip: Managing Python Packages and Dependencies (Quiz)
• How to Publish Your Own Python Package to PyPI (Course)
• Publishing Python Packages to PyPI (Course)
• How to Publish an Open-Source Python Package to PyPI (Quiz)
• Unleashing the Power of the Console With Rich (Course)
• Making HTTP Requests With Python (Course)
• Python's Requests Library (Quiz)