|
Building packages
There are a number of techniques and tools available for creating and distributing
packages. The truth is that Python does not have a great history of standardizing the
packaging process. There have been multiple projects started in the first decade of the 21st
century to streamline this process but not with a lot of success. In the last decade, we have
had some success, thanks to the initiatives of the Python Packaging Authority (PyPA).
In this section, we will be covering techniques of building packages, accessing the
packages in our program, and publishing and sharing the packages as per the guidelines
provided by PyPA.
We will start with package names, followed by the use of an initialization file, and then
jump into building a sample package.
Naming
Package names should follow the same rule for naming as for modules, which is lowercase
with no underscores. Packages act like structured modules.
Package initialization file
A package can have an optional source file named __init__.py (or simply an init
file). The presence of the init file (even a blank one) is recommended to mark folders as
packages. Since Python release 3.3 or later, the use of an init file is optional (PEP 420:
Implicit Namespace Packages). There can be multiple purposes of using this init file and
there is always a debate about what can go inside an init file versus what cannot go in.
A few uses of the init file are discussed here:
• Empty __init__.py: This will force developers to use explicit imports and manage
the namespaces as they like. As expected, developers have to import separate
modules, which can be tedious for a large package.
• Full import in __init__.py: In this case, developers can import the package and
then refer to the modules directly in their code using the package name or its alias
name. This provides more convenience but at the expense of maintaining the list of
all imports in the __init__ file.
|