Via Bernat Gabor bernat.tech – a great article on Python and package management:

pip 19.0 has been released on 22nd January 2019. On the feature list most notably it now supports PEP-517, which by default is turned on when that the project has a pyproject.toml at the root folder. The PEP in question has been created in 2015 and accepted in 2017. Even though it took a while until pip implemented it, the release and the issues that followed it up confirmed that many people are not at all familiar with it.

I’ve remarked that the Python packaging has a reputation of a kinda black box. There’s a lot of unknown, and people mostly get by with just copying other projects build configurations and roll with it.

In this first post I will give a broad overview of how Python packaging works along with the type of packages it has.

Bernat goes through an example using a simplified library for random pug quotes.

We have four distinct content type here:

What would it mean for our pugs package to be available on a user machine’s interpreter? Ideally, the user should be able to import it and call functions from it once it starts up the interpreter:

• the business logic code (what’s inside the src folder),
• the test code (tests folder and tox.ini),
• the packaging code and metadata (setup.py, setup.cfg, LICENSE.txt, README.rst – note we use nowadays the de facto standard packaging tool setuptools),
• files helping with project management and maintenance:
  • continuous integration (azure-pipelines.yml)
  • version control (.git)
  • project management (for example a potential .github folder).

Python package types

A package during installation must generate at least two types of content to be put in the site package: a metadata folder about the package contents the {package}-{version}.dist-info and the business logic files.

• source tree – contains all project files available on the developers’ machine/repository (business logic, tests, packaging data, CI files, IDE files, SVC etc.) – for example, see example project above.
• source distribution – contains code files required to build a wheel (business logic + packaging data + often also the unit tests files to validate the build; notably lacks developer environment content such as CI/IDE/version control files) – format: pugs-0.0.1.tar.gz.
• wheel – contains the package metadata and source files to be put into the site packages folder – format: pugs-0.0.1-py2.py3-none-any.whl.

See the entire run through in the article here