Python Dependency Management for Stable Scripts

A Python script that worked perfectly last month can fail today without anyone touching its code. A library released a new version with a changed function, a dependency of a dependency dropped support for your Python version, or a new server installed slightly different packages from the old one. These failures are frustrating because the cause is outside the script itself. Python dependency management is the practice of controlling exactly which packages and versions a script uses, so it behaves the same on every machine and changes only when you decide. This guide covers virtual environments, pinned requirements, secure installs and how to update dependencies on your own schedule.

Why scripts break when nothing changed

Most Python scripts rely on packages from the Python Package Index: HTTP clients, spreadsheet readers, database drivers, API libraries. If a script's setup simply installs the latest version of each, then each new installation can pull in different versions from the last one. Usually that is harmless. Occasionally a release changes behaviour, removes a function or conflicts with another package, and the script fails in a way that is hard to trace. Shared system-wide installations make this worse, because updating a package for one script can break another.

Use one virtual environment per project

The Python documentation explains that the venv module creates lightweight virtual environments, each with its own independent set of Python packages, built on top of an existing Python installation (Python: venv). Giving each script or project its own environment means its packages cannot interfere with any other project's.

The same documentation describes how environments are best treated: kept in a directory such as .venv in the project, not checked into source control, considered disposable so they are simple to delete and recreate, and not considered movable or copyable, so you recreate them in the target location instead. In practice, the environment is not the record of what a project needs. The requirements file is.

Pin versions in a requirements file

The pip documentation describes requirements files as files listing items to install with pip (pip: User Guide). Its guide to repeatable installs explains that pinning package versions in the requirements file, using the == operator to require a specific version, protects you from bugs or incompatibilities in newly released versions. It also notes that pip freeze can generate such a file, pinning not only the top-level packages but all their transitive dependencies (pip: Repeatable Installs).

Many teams keep two files: a short one listing the packages the code directly uses, with loose version ranges, and a complete pinned file generated from it that is used for installation. You edit the short one when adding or upgrading a dependency, regenerate the pinned one and commit both. Several third-party tools automate this workflow; the principle is the same whichever you use.

Python dependency management for secure installs

Pinning versions controls which version is installed, but not which exact file. For stricter control, pip offers hash-checking mode, enabled with the require-hashes option, as part of its guidance on secure installs (pip: Secure installs). The documentation explains that this mode uses local hashes embedded in the requirements file to protect against remote tampering and network issues, and that it is all or nothing: once any requirement has a hash, every requirement needs one. It adds some maintenance, so it suits scripts that handle sensitive data or run in production environments where supply-chain risk matters.

Other good habits for installs:

• Install only from trusted package indexes
• Check the package name carefully before adding a new dependency, since similarly named packages are easy to confuse
• Prefer well-maintained packages with active releases over abandoned ones
• Keep the number of dependencies small; each one is code you are trusting

Check environments for conflicts

The pip documentation describes pip check as a command that verifies installed packages have compatible dependencies (pip: pip check). Run it after installing and in CI, so conflicts are caught before deployment rather than when the script first imports the affected package.

Worked example: a hypothetical dependency policy

The table below is a hypothetical policy for a team running a dozen Python automation scripts. It shows the decisions to make, not rules every team should follow.

AreaPolicyEnvironmentsOne virtual environment per script repository, recreated on each deployDirect dependenciesListed in a short file with compatible version rangesInstalled versionsFully pinned file generated from the short file and committedHashesRequired for scripts that handle payment or personal dataUpdatesReviewed monthly; security fixes applied as soon as possibleTestingTests and pip check run in CI on every dependency changePython versionPinned per repository and upgraded deliberately

Update on your own schedule

Pinning does not mean never updating. Old versions accumulate security issues and drift away from the APIs you integrate with. Plan updates:

• Review available updates on a regular schedule
• Apply security fixes promptly, using your package index's advisories or a vulnerability scanner
• Update a few packages at a time, so a failure points to a likely cause
• Run tests and a trial run with real-shaped data before deploying

Our guide to Python automation scripts covers the testing and monitoring habits that make updates safe.

Document how to rebuild the environment

Write down, in the project README, the exact steps to create the environment from scratch: which Python version to install, the command to create the virtual environment and the command to install from the pinned file. Then test those steps on a clean machine or container. If a new team member, or a replacement server after an outage, cannot rebuild the environment by following the README, the dependency management is not finished.

Pin the Python version too

Dependencies are not the only moving part. Record which Python version each script uses, install that version in deployments and upgrade deliberately, testing the script on the new version first. Container images are a convenient way to fix both the Python version and the system libraries a script needs.

Keep configuration separate

Dependency files describe what code a script runs; they should not contain settings or secrets. Our guide to Python environment variables explains how to keep configuration and credentials outside the code and the dependency files.

Frequently Asked Questions

Why use a virtual environment for every project?

Each environment has its own independent set of packages, so one project's versions cannot break another. The Python documentation also recommends treating environments as disposable and recreating rather than copying them.

What does pinning dependencies mean?

Requiring an exact version of each package, usually with the == operator in a requirements file, so every installation uses the same versions.

Is pip freeze enough?

It produces a pinned list of everything installed, including transitive dependencies. For stricter guarantees, add hash checking, and keep a separate short list of direct dependencies for easier updates.

How often should dependencies be updated?

On a regular schedule that suits the team, with security fixes applied promptly and every update tested before deployment.

Make scripts behave the same everywhere

We set up dependency management, testing and deployment for Python automation so scripts change only when you decide. See our custom app development services, or talk to us about Python dependency management.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.