Links
setup.cfg filespyproject.toml filespkg_resourcesProject
setup() Keywordsdependency_linkszip_safe flagsetuptools commandsNote
This document is being retained solely until thesetuptools documentationathttps://setuptools.pypa.io/en/latest/setuptools.htmlindependently covers all of the relevant information currently included here.
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 notnecessarily binary, though, because it might contain only Python source codeand/or byte-code; and we don’t call it a package, because that word is alreadyspoken for in Python. (And “installer” is a term specific to the world ofmainstream desktop systems.)
A built distribution is how you make life as easy as possible for installers ofyour module distribution: for users of RPM-based Linux systems, it’s a binaryRPM; for Windows users, it’s an executable installer; for Debian-based Linuxusers, it’s a Debian package; and so forth. Obviously, no one person will beable to create built distributions for every platform under the sun, so theDistutils are designed to enable module developers to concentrate on theirspecialty—writing code and creating source distributions—while anintermediary species calledpackagers springs up to turn source distributionsinto built distributions for as many platforms as there are packagers.
Of course, the module developer could be their own packager; or the packager couldbe a volunteer “out there” somewhere who has access to a platform which theoriginal developer does not; or it could be software periodically grabbing newsource distributions and turning them into built distributions for as manyplatforms as the software has access to. Regardless of who they are, a packageruses the setup script and thebdist command family to generate builtdistributions.
As a simple example, if I run the following command in the Distutils sourcetree:
pythonsetup.pybdist
then the Distutils builds my module distribution (the Distutils itself in thiscase), does a “fake” installation (also in thebuild directory), andcreates the default type of built distribution for my platform. The defaultformat for built distributions is a “dumb” tar file on Unix, and a simpleexecutable installer on Windows. (That tar file is considered “dumb” because ithas to be unpacked in a specific location to work.)
Thus, the above command on a Unix system createsDistutils-1.0.plat.tar.gz; unpacking this tarball from the right placeinstalls the Distutils just as though you had downloaded the source distributionand runpythonsetup.pyinstall. (The “right place” is either the root ofthe filesystem or Python’sprefix directory, depending on the optionsgiven to thebdist_dumb command; the default is to make dumbdistributions relative toprefix.)
Obviously, for pure Python distributions, this isn’t any simpler than justrunningpythonsetup.pyinstall—but for non-pure distributions, whichinclude extensions that would need to be compiled, it can mean the differencebetween someone being able to use your extensions or not. And creating “smart”built distributions, such as an RPM package or an executable installer forWindows, is far more convenient for users even if your distribution doesn’tinclude any extensions.
Thebdist command has a--formats option, similar to thesdist command, which you can use to select the types of builtdistribution to generate: for example,
pythonsetup.pybdist--format=zip
would, when run on a Unix system, createDistutils-1.0.plat.zip—again, this archive would be unpackedfrom the root directory to install the Distutils.
The available formats for built distributions are:
Format | Description | Notes |
|---|---|---|
| gzipped tar file( | (1) |
| bzipped tar file( | |
| xzipped tar file( | |
| compressed tar file( | (3) |
| tar file ( | |
| zip file ( | (2),(4) |
| RPM | (5) |
| Solarispkgtool | |
| HP-UXswinstall |
Changed in version 3.5:Added support for thexztar format.
Notes:
default on Unix
default on Windows
requires externalcompress utility.
requires either externalzip utility orzipfile module (partof the standard Python library since Python 1.6)
requires externalrpm utility, version 3.0.4 or better (userpm--version to find out which version you have)
You don’t have to use thebdist command with the--formatsoption; you can also use the command that directly implements the format you’reinterested in. Some of thesebdist “sub-commands” actually generateseveral similar formats; for instance, thebdist_dumb commandgenerates all the “dumb” archive formats (tar,gztar,bztar,xztar,ztar, andzip), andbdist_rpm generates bothbinary and source RPMs. Thebdist sub-commands, and the formatsgenerated by each, are:
Command | Formats |
|---|---|
bdist_dumb | tar, gztar, bztar, xztar, ztar, zip |
bdist_rpm | rpm, srpm |
The following sections give details on the individualbdist_*commands.
The RPM format is used by many popular Linux distributions, including Red Hat,SuSE, and Mandrake. If one of these (or any of the other RPM-based Linuxdistributions) is your usual environment, creating RPM packages for other usersof that same distribution is trivial. Depending on the complexity of your moduledistribution and differences between Linux distributions, you may also be ableto create RPMs that work on different RPM-based distributions.
The usual way to create an RPM of your module distribution is to run thebdist_rpm command:
pythonsetup.pybdist_rpm
or thebdist command with the--format option:
pythonsetup.pybdist--formats=rpm
The former allows you to specify RPM-specific options; the latter allows you toeasily specify multiple formats in one run. If you need to do both, you canexplicitly specify multiplebdist_* commands and their options:
pythonsetup.pybdist_rpm--packager="John Doe <jdoe@example.org>" \bdist_dumb--dumb-option=foo
Creating RPM packages is driven by a.spec file, much as using theDistutils is driven by the setup script. To make your life easier, thebdist_rpm command normally creates a.spec file based on theinformation you supply in the setup script, on the command line, and in anyDistutils configuration files. Various options and sections in the.spec file are derived from options in the setup script as follows:
RPM | Distutils setup script option |
|---|---|
Name |
|
Summary (in preamble) |
|
Version |
|
Vendor |
|
Copyright |
|
Url |
|
%description (section) |
|
Additionally, there are many options in.spec files that don’t havecorresponding options in the setup script. Most of these are handled throughoptions to thebdist_rpm command as follows:
RPM | bdist_rpm option | default value |
|---|---|---|
Release |
| “1” |
Group |
| “Development/Libraries” |
Vendor |
| (see above) |
Packager |
| (none) |
Provides |
| (none) |
Requires |
| (none) |
Conflicts |
| (none) |
Obsoletes |
| (none) |
Distribution |
| (none) |
BuildRequires |
| (none) |
Icon |
| (none) |
Obviously, supplying even a few of these options on the command-line would betedious and error-prone, so it’s usually best to put them in the setupconfiguration file,setup.cfg—see sectionWriting the Setup Configuration File. Ifyou distribute or package many Python module distributions, you might want toput options that apply to all of them in your personal Distutils configurationfile (~/.pydistutils.cfg). If you want to temporarily disablethis file, you can pass the--no-user-cfg option tosetup.py.
There are three steps to building a binary RPM package, all of which arehandled automatically by the Distutils:
create a.spec file, which describes the package (analogous to theDistutils setup script; in fact, much of the information in the setup scriptwinds up in the.spec file)
create the source RPM
create the “binary” RPM (which may or may not contain binary code, dependingon whether your module distribution contains Python extensions)
Normally, RPM bundles the last two steps together; when you use the Distutils,all three steps are typically bundled together.
If you wish, you can separate these three steps. You can use the--spec-only option to makebdist_rpm just create the.spec file and exit; in this case, the.spec file will bewritten to the “distribution directory”—normallydist/, butcustomizable with the--dist-dir option. (Normally, the.specfile winds up deep in the “build tree,” in a temporary directory created bybdist_rpm.)
Starting with Python 2.6, distutils is capable of cross-compiling betweenWindows platforms. In practice, this means that with the correct toolsinstalled, you can use a 32bit version of Windows to create 64bit extensionsand vice-versa.
To build for an alternate platform, specify the--plat-name optionto the build command. Valid values are currently ‘win32’, and ‘win-amd64’.For example, on a 32bit version of Windows, you could execute:
pythonsetup.pybuild--plat-name=win-amd64
to build a 64bit version of your extension.
To cross-compile, you must download the Python source code and cross-compilePython itself for the platform you are targeting - it is not possible from abinary installation of Python (as the .lib etc file for other platforms arenot included.) In practice, this means the user of a 32 bit operatingsystem will need to use Visual Studio 2008 to open thePCbuild/PCbuild.sln solution in the Python source tree and build the“x64” configuration of the ‘pythoncore’ project before cross-compilingextensions is possible.
Note that by default, Visual Studio 2008 does not install 64bit compilers ortools. You may need to reexecute the Visual Studio setup process and selectthese tools (using Control Panel->[Add/Remove] Programs is a convenient way tocheck or modify your existing install.)
Starting with Python 2.3, a postinstallation script can be specified with the--install-script option. The basename of the script must bespecified, and the script filename must also be listed in the scripts argumentto the setup function.
This script will be run at installation time on the target system after all thefiles have been copied, withargv[1] set to-install, and again atuninstallation time before the files are removed withargv[1] set to-remove.
The installation script runs embedded in the windows installer, every output(sys.stdout,sys.stderr) is redirected into a buffer and will bedisplayed in the GUI after the script has finished.
Some functions especially useful in this context are available as additionalbuilt-in functions in the installation script.
These functions should be called when a directory or file is created by thepostinstall script at installation time. It will registerpath with theuninstaller, so that it will be removed when the distribution is uninstalled.To be safe, directories are only removed if they are empty.
This function can be used to retrieve special folder locations on Windows likethe Start Menu or the Desktop. It returns the full path to the folder.csidl_string must be one of the following strings:
"CSIDL_APPDATA""CSIDL_COMMON_STARTMENU""CSIDL_STARTMENU""CSIDL_COMMON_DESKTOPDIRECTORY""CSIDL_DESKTOPDIRECTORY""CSIDL_COMMON_STARTUP""CSIDL_STARTUP""CSIDL_COMMON_PROGRAMS""CSIDL_PROGRAMS""CSIDL_FONTS"
If the folder cannot be retrieved,OSError is raised.
Which folders are available depends on the exact Windows version, and probablyalso the configuration. For details refer to Microsoft’s documentation of theSHGetSpecialFolderPath() function.
This function creates a shortcut.target is the path to the program to bestarted by the shortcut.description is the description of the shortcut.filename is the title of the shortcut that the user will see.argumentsspecifies the command line arguments, if any.workdir is the working directoryfor the program.iconpath is the file containing the icon for the shortcut,andiconindex is the index of the icon in the fileiconpath. Again, fordetails consult the Microsoft documentation for theIShellLinkinterface.