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.
Adafruit publishes a wide range of writing and video content, including interviews and reporting on the maker market and the wider technology world. Our standards page is intended as a guide to best practices that Adafruit uses, as well as an outline of the ethical standards Adafruit aspires to. While Adafruit is not an independent journalistic institution, Adafruit strives to be a fair, informative, and positive voice within the community – check it out here: adafruit.com/editorialstandards
Stop breadboarding and soldering – start making immediately! Adafruit’s Circuit Playground is jam-packed with LEDs, sensors, buttons, alligator clip pads and more. Build projects with Circuit Playground in a few minutes with the drag-and-drop MakeCode programming site, learn computer science using the CS Discoveries class on code.org, jump into CircuitPython to learn Python and hardware together, TinyGO, or even use the Arduino IDE. Circuit Playground Express is the newest and best Circuit Playground board, with support for CircuitPython, MakeCode, and Arduino. It has a powerful processor, 10 NeoPixels, mini speaker, InfraRed receive and transmit, two buttons, a switch, 14 alligator clip pads, and lots of sensors: capacitive touch, IR proximity, temperature, light, motion and sound. A whole wide world of electronics and coding is waiting for you, and it fits in the palm of your hand.
Have an amazing project to share? The Electronics Show and Tell is every Wednesday at 7pm ET! To join, head over to YouTube and check out the show’s live chat – we’ll post the link there.
