Note that the name of the distribution is specified independently with the
name option, and there’s no rule that says it has to be the same as
the name of the sole module in the distribution (although that’s probably a good
convention to follow). However, the distribution name is used to generate
filenames, so you should stick to letters, digits, underscores, and hyphens.

Since py_modules is a list, you can of course specify multiple
modules, eg. if you’re distributing modules foo and bar, your
setup might look like this:

If you have more than a couple of modules to distribute, especially if they are
in multiple packages, it’s probably easier to specify whole packages rather than
individual modules. This works even if your modules are not in a package; you
can just tell the Distutils to process modules from the root package, and that
works the same as any other package (except that you don’t have to have an
__init__.py file).

More typically, though, you will want to distribute multiple modules in the same
package (or in sub-packages). For example, if the foo and bar
modules belong in package foobar, one way to layout your source tree is

<root>/setup.pyfoobar/__init__.pyfoo.pybar.py

This is in fact the default layout expected by the Distutils, and the one that
requires the least work to describe in your setup script:

If you have sub-packages, they must be explicitly listed in packages,
but any entries in package_dir automatically extend to sub-packages.
(In other words, the Distutils does not scan your source tree, trying to
figure out which directories correspond to Python packages by looking for
__init__.py files.) Thus, if the default layout grows a sub-package:

Extension modules are specified using the ext_modules option.
package_dir has no effect on where extension source files are found;
it only affects the source for pure Python modules. The simplest case, a
single extension module in a single C source file, is:

<root>/setup.pyfoo.c

If the foo extension belongs in the root package, the setup script for
this could be

If you use the reStructuredText syntax in the long_description field and
docutils is installed you can check if the syntax is fine with the
check command, using the restructuredtext option.

For example, if the setup.py script is changed like this:

fromdistutils.coreimportsetupdesc="""\My description==============This is the description of the ``foobar`` package."""setup(name='foobar',version='1',author='tarek',author_email='tarek@ziade.org',url='http://example.com',long_description=desc)

Where the long description is broken, check will be able to detect it
by using the docutils parser:

The distutils.core.setup() function provides a command-line interface
that allows you to query the metadata fields of a project through the
setup.py script of a given project:

$ python setup.py --name
distribute

This call reads the name metadata by running the
distutils.core.setup() function. Although, when a source or binary
distribution is created with Distutils, the metadata fields are written
in a static file called PKG-INFO. When a Distutils-based project is
installed in Python, the PKG-INFO file is copied alongside the modules
and packages of the distribution under NAME-VERSION-pyX.X.egg-info,
where NAME is the name of the project, VERSION its version as defined
in the Metadata, and pyX.X the major and minor version of Python like
2.7 or 3.2.

You can read back this static file, by using the
distutils.dist.DistributionMetadata class and its
read_pkg_file() method: