Python: Setting up the environment
2026-02-21 02:49 Diff
https://hexlet.io/courses/python-setup-environment/lessons/poetry-and-dependencies/theory_unit

In this lesson, we'll take a closer look at working with dependencies with Poetry.

Adding and removing dependencies

In the last lesson, we created a project named hello. Let's return to it and add the colorama package — a dependency for hello. It is a popular library that allows you to colorize text in the terminal.

We will add dependencies with the command poetry add NAME:

Now we will look at the tool.poetry.dependencies section of the pyproject.toml file. You'll find the following:

As you can see, colorama is installed in the virtual environment and appears in the list of project dependencies. If we want to run a code, we can run the poetry install command and get all the necessary dependencies.

Note the text "^0.4.5". It doesn't just mean specifically 0.4.5. The versions from 0.4.5 up to 0.5.0 will be considered compatible. You can also give a specific version, list several permissible versions, or manually specify a range. You can learn more about this variety in the documentation.

Now let's try to remove the dependencies with the command poetry remove NAME. Python will remove the uninstalled packages from the pyproject.toml file automatically:

Dependency groups

Many tools for developing Python projects are in Python. However, they're usually not needed to run the code. Take, for example, Pytest, a popular framework for writing tests. This package has many dependencies of its own. In a large project, these development tools can take up a lot of space.

The problem is that users do not need all these dependencies because they do not run any tests. However, the user gets all the dependencies with the program and wastes space by having to store them.

Fortunately, Poetry allows you to describe these packages as a group of dependencies. We will consider all created groups when building the virtual environment, but only the dependencies from the [tool.poetry.dependencies] group will reach the end user.

Add the Pytest package to the hello project. We'll put it in the dev group. Dev is the usual name for the development tools and environment. Let's see how it works:

When you run the command yourself, pay attention to how many packages we will install with the pytest we need. There is a new entry in the pyproject.toml file:

As a result, we can run Pytest. Don't forget to write poetry run pytest instead of pytest. We install the program in a virtual environment and cannot see it from the outside. Let's try running it:

The poetry run command doesn't just run commands from the virtual environment. It runs any program in the context of the virtual environment. For example, you can use the system program which to find out where the executable file pytest is:

Now let's try to remove the dependency. To do this, you must indicate its group:

Updating dependencies

To update all dependencies, run the command poetry update. To update a specific dependency, run poetry update NAME. Dependencies will update according to the ranges specified.

Lock file

In the previous step, we created each new installation of dependencies and then updated it in the poetry.lock file. Let's discuss this file in more detail. As we already discussed, the file pyproject.toml specifies the dependencies. Each dependency may have its dependencies, which may have their dependencies etc. Dependencies of dependencies are transitive dependencies, and they're not always easy to deal with. The dependency system can be very confusing.

There is a term for such a situation — dependency hell. The problem is that we don't capture versions of transitive dependencies in any way. Here's an example:

  • Our project has a dependent package, A, with a fixed version 1.3.2
  • Dependency A has dependent package B with version *

In this situation, even without the lock file, the poetry install command would install:

  • For A — the specified version
  • For B — the latest available version from the repository

In other words, the choice of version isn't determined. If the author updates B and breaks backward compatibility, A will stop working, so the whole project will crash.

You can manually track dependencies of all dependencies and explicitly write their versions in pyproject.toml. But this method may not work because packages are constantly updated and changed. It's also hard to track manually because there are too many dependencies - even a project with five dependencies will have hundreds of transitive dependencies.

Another option would be to require that the creators of all libraries always specify the version. This option will not work because of the human factor this time.

There is one solution that will work, a lock file. It is essentially automated dependency tracking. The contents of a lock file look something like this:

The first run of the dependency installer will create this file. All installed dependencies are written there, including transitive ones with versions and [hash sums] (https://en.wikipedia.org/wiki/Checksum).

On subsequent runs, the `poetry install' command will always put the data from the lock file. It works even if you delete the .venv folder or add new versions of packages to pyproject.toml. Running it after any amount of time will produce the same result. Now we can say that the project will run for any user at any time.

The lock file doesn't affect the behavior of the `update' command for direct dependencies. Let's say the package in our pyproject.toml file has a new version. In this case, Poetry will check if it's possible to update. If so, it will download the new version and automatically update the lock file.

If we don't want to install packages, we can use the poetry update --lock command. It will check which the new versions match the versions specified in the configuration and only update the lock file.