The structure of a Python package is defined by a few specifications (https://packaging.python.org/specifications/) and PEPs (short for Python Enhancement Proposals, such as PEP517—https://www.python.org/dev/peps/pep-0517/, PEP518—https://www.python.org/dev/peps/pep-0518/, and PEP427—https://www.python.org/dev/peps/pep-0427/), and the overall definition comes from the Python Packaging Authority (PyPA). In essence, a package is required to have, in addition to the actual code, a special file with metadata, including the package name, the description version, the tags, Python version support details, the authors, and the dependencies. This file could be a Python setup.py file—which was the standard solution for a long time—or a pyproject.toml file. The latter is a new, safer approach, but does not have as well-designed a specification.
It is entirely possible to build a package manually. All it takes is a little structure and a file with the metadata. It is, however, a tedious task, so there are quite a few packages designed to help with packaging. A standard bundle is distutuls. There is also setuptools. Both of them expect a setup.py file.
One of the challenges with package building is managing dependencies between packages. One package may depend on another, which may depend on several more—so don't be surprised if your package requires the installation of dozens of other packages. There is even a fair chance that some of those packages will depend upon different versions of the same package, so someone will have to figure out a way to install versions that suit all the requirements or somehow install two versions of the same package. This is a challenge that the previous generation of package builders didn't fully solve.
Recently, a few new tools arrived—namely, flit and poetry—and both of them
support pyptoject.toml files and work well to resolve dependencies. In this chapter, we will use poetry to build our package. This package has a slick and expressive interface and supports .toml format. It also builds a dedicated virtual environment for developers and has two levels of dependency description: a flexible list of packages required for the user, and one explicit and precise package, for developers, which contains a list of exact versions of all dependency packages installed on the developer's machine. It also has tools for dependency diagnostics and package publishing.