If you’re going to start giving code away, the first thing to do is to give it a unique name

and clean up its directory structure. For example, a typical library package might look

something like this:

To make the package something that you can distribute, first write a setup.py file that

looks like this:

Next, make a file MANIFEST.in that lists various nonsource files that you want to include

in your package:

Make sure the setup.py and MANIFEST.in files appear in the top-level directory of your

package. Once you have done this, you should be able to make a source distribution by

typing a command such as this:

This will create a file such as projectname-1.0.zip or projectname-1.0.tar.gz, depending

the `Python Package Index <http://pypi.python.org/>`_.

For pure Python code, writing a plain setup.py file is usually straightforward. One potential

gotcha is that you have to manually list every subdirectory that makes up the

packages source code. A common mistake is to only list the top-level directory of a

package and to forget to include package subcomponents. This is why the specification

for packages in setup.py includes the list packages=['projectname', 'project

name.utils'].

As most Python programmers know, there are many third-party packaging options,

including setuptools, distribute, and so forth. Some of these are replacements for the

distutils library found in the standard library. Be aware that if you rely on these

packages, users may not be able to install your software unless they also install the

required package manager first. Because of this, you can almost never go wrong by

keeping things as simple as possible. At a bare minimum, make sure your code can be

installed using a standard Python 3 installation. Additional features can be supported

as an option if additional packages are available.

Packaging and distribution of code involving C extensions can get considerably more

complicated. Chapter 15 on C extensions has a few details on this. In particular, see

Recipe 15.2.