 |
 |
 |
Distributing Python Modules |  |
 |
|
|
|
|
Distributing Python Modules | |
|
|
A ``built distribution'' is what you're probably used to thinking of either as a ``binary package'' or an ``installer'' (depending on your background). It's not necessarily binary, though, because it might contain only Python source code and/or byte-code; and we don't call it a package, because that word is already spoken for in Python. (And ``installer'' is a term specific to the Windows world. ** do Mac people use it? **)
A built distribution is how you make life as easy as possible for installers of your module distribution: for users of RPM-based Linux systems, it's a binary RPM; for Windows users, it's an executable installer; for Debian-based Linux users, it's a Debian package; and so forth. Obviously, no one person will be able to create built distributions for every platform under the sun, so the Distutils are designed to enable module developers to concentrate on their specialty--writing code and creating source distributions--while an intermediary species of packager springs up to turn source distributions into built distributions for as many platforms as there are packagers.
Of course, the module developer could be his own packager; or the
packager could be a volunteer ``out there'' somewhere who has access to
a platform which the original developer does not; or it could be
software periodically grabbing new source distributions and turning them
into built distributions for as many platforms as the software has
access to. Regardless of the nature of the beast, a packager uses the
setup script and the bdist command family to generate built
distributions.
As a simple example, if I run the following command in the Distutils source tree:
python setup.py bdist
Thus, the above command on a Unix system creates
Distutils-0.9.1.plat.tar.gz; unpacking this tarball
from the right place installs the Distutils just as though you had
downloaded the source distribution and run python setup.py
install. (The ``right place'' is either the root of the filesystem or
Python's prefix directory, depending on the options given to
the bdist_dumb command; the default is to make dumb
distributions relative to prefix.)
Obviously, for pure Python distributions, this isn't a huge win--but for non-pure distributions, which include extensions that would need to be compiled, it can mean the difference between someone being able to use your extensions or not. And creating ``smart'' built distributions, such as an RPM package or an executable installer for Windows, is a big win for users even if your distribution doesn't include any extensions.
The bdist command has a --formats option,
similar to the sdist command, which you can use to select the
types of built distribution to generate: for example,
python setup.py bdist --format=zip
The available formats for built distributions are:
| Format | Description | Notes |
|---|---|---|
| gzipped tar file (.tar.gz) | (1),(3) | |
| compressed tar file (.tar.Z) | (3) | |
| tar file (.tar) | (3) | |
| zip file (.zip) | (4) | |
| RPM | (5) | |
| source RPM | (5) ** to do! ** | |
| self-extracting ZIP file for Windows | (2),(6) |
Notes:
rpm -version to find out which version you have)
bdist_wininst? **
You don't have to use the bdist command with the
--formats option; you can also use the command that
directly implements the format you're interested in. Some of these
bdist ``sub-commands'' actually generate several similar
formats; for instance, the bdist_dumb command generates all
the ``dumb'' archive formats (tar, ztar, gztar, and
zip), and bdist_rpm generates both binary and source
RPMs. The bdist sub-commands, and the formats generated by
each, are:
| Command | Formats |
|---|---|
| tar, ztar, gztar, zip | |
| rpm, srpm | |
| wininst |
The following sections give details on the individual bdist_*
commands.
|
|
|
Distributing Python Modules | |
|
|