Python: Setting up the environment
2026-02-21 03:01 Diff
https://hexlet.io/courses/python-setup-environment/lessons/packages-and-indexes/theory_unit

At one point, developers realize they want to share their code with other programmers. They can write a library of functions or a ready-made program and then pass it on to others. Programmers usually use packages used in this case.

How packages work

Packages are sets of modules and nested packages. But that's not the only meaning of the term. In a broader sense, a package is a unit of code exchange between developers.

Python packages contain source code and metadata — additional information, including:

  • Purpose of the package
  • The current version of the package and a list of previous versions
  • Compatibility with different versions of Python
  • The license under which creators distribute the package
  • List of package dependencies

Index

Suppose we've created a finished package and want to share it with the world. The assembled package is an ordinary file we can pass on to another person. It is the simplest case.

Let's complicate the task and imagine that our package needs another package to work. It gets complex, so we need to add more packages, which sometimes need more packages. And this cycle can go on forever.

To handle this complexity, we use package repositories. They are usually called indexes in Python. They also provide a user-friendly interface for searching for packages and familiarizing yourself with their descriptions. It's usually in the form of a web page. The most popular package index is PyPI (Python Package Index). It is what you'll be working with most of the time.

But there are other indexes. Most package management tools can handle a variety of indexes. For example, many companies use custom indexes to host packages that aren't open source. Another index is Test PyPI. It is an index of packages used to teach the Python packaging system.

It's not very convenient to display hundreds or thousands of training packages. They get caught in searches, they take all the names, and others clutter up the main index.

The test index works just like the main PyPI. It allows you to upload and download packages but periodically deletes all data.

Indexes versus code repositories

Some repositories don't store packages but only index and manage package metadata. The code is on GitHub, BitBucket, and GitLab, source code repositories.

This approach generally works for interpreted languages; you need access to the source code to use the package code anyway.

However, storing code on third-party resources with metadata sources has several drawbacks.

First, only the author of the code owns the published code. The author can delete his repository, but the information about the package in the index remains. People who already started using the deleted package won't be able to build their projects.

Second, GitHub and other Git repositories do not guarantee the integrity of the data when we use tags and branches alone. And this is the most common way of tying code state to information in the index, meaning that anyone with access to the repository can rewrite its history.

Even if you bind package versions in the index to hash sums of commits in Git, changing the history will lead to the first problem: the package version will point to a non-existent source. If we overwrite the history, the hash sums of the commits will also change.

Both of these reasons break an essential feature of the packaging system: the reproducibility of the repository. This property implies that any project with an accurate description of its dependencies will run at any time, even if we use old versions of packages and the interpreter.

For reproducibility, a centralized index that independently stores all versions of all packages in unmodified form is more appropriate. It gives the programmer a better guarantee that an old project will run at any time, under any circumstances.