1.. _distutils-intro: 2 3**************************** 4An Introduction to Distutils 5**************************** 6 7.. include:: ./_setuptools_disclaimer.rst 8 9This document covers using the Distutils to distribute your Python modules, 10concentrating on the role of developer/distributor: if you're looking for 11information on installing Python modules, you should refer to the 12:ref:`install-index` chapter. 13 14 15.. _distutils-concepts: 16 17Concepts & Terminology 18====================== 19 20Using the Distutils is quite simple, both for module developers and for 21users/administrators installing third-party modules. As a developer, your 22responsibilities (apart from writing solid, well-documented and well-tested 23code, of course!) are: 24 25* write a setup script (:file:`setup.py` by convention) 26 27* (optional) write a setup configuration file 28 29* create a source distribution 30 31* (optional) create one or more built (binary) distributions 32 33Each of these tasks is covered in this document. 34 35Not all module developers have access to a multitude of platforms, so it's not 36always feasible to expect them to create a multitude of built distributions. It 37is hoped that a class of intermediaries, called *packagers*, will arise to 38address this need. Packagers will take source distributions released by module 39developers, build them on one or more platforms, and release the resulting built 40distributions. Thus, users on the most popular platforms will be able to 41install most popular Python module distributions in the most natural way for 42their platform, without having to run a single setup script or compile a line of 43code. 44 45 46.. _distutils-simple-example: 47 48A Simple Example 49================ 50 51The setup script is usually quite simple, although since it's written in Python, 52there are no arbitrary limits to what you can do with it, though you should be 53careful about putting arbitrarily expensive operations in your setup script. 54Unlike, say, Autoconf-style configure scripts, the setup script may be run 55multiple times in the course of building and installing your module 56distribution. 57 58If all you want to do is distribute a module called ``foo``, contained in a 59file :file:`foo.py`, then your setup script can be as simple as this:: 60 61 from distutils.core import setup 62 setup(name='foo', 63 version='1.0', 64 py_modules=['foo'], 65 ) 66 67Some observations: 68 69* most information that you supply to the Distutils is supplied as keyword 70 arguments to the :func:`~distutils.core.setup` function 71 72* those keyword arguments fall into two categories: package metadata (name, 73 version number) and information about what's in the package (a list of pure 74 Python modules, in this case) 75 76* modules are specified by module name, not filename (the same will hold true 77 for packages and extensions) 78 79* it's recommended that you supply a little more metadata, in particular your 80 name, email address and a URL for the project (see section :ref:`setup-script` 81 for an example) 82 83To create a source distribution for this module, you would create a setup 84script, :file:`setup.py`, containing the above code, and run this command from a 85terminal:: 86 87 python setup.py sdist 88 89For Windows, open a command prompt window (:menuselection:`Start --> 90Accessories`) and change the command to:: 91 92 setup.py sdist 93 94:command:`sdist` will create an archive file (e.g., tarball on Unix, ZIP file on Windows) 95containing your setup script :file:`setup.py`, and your module :file:`foo.py`. 96The archive file will be named :file:`foo-1.0.tar.gz` (or :file:`.zip`), and 97will unpack into a directory :file:`foo-1.0`. 98 99If an end-user wishes to install your ``foo`` module, all they have to do is 100download :file:`foo-1.0.tar.gz` (or :file:`.zip`), unpack it, and---from the 101:file:`foo-1.0` directory---run :: 102 103 python setup.py install 104 105which will ultimately copy :file:`foo.py` to the appropriate directory for 106third-party modules in their Python installation. 107 108This simple example demonstrates some fundamental concepts of the Distutils. 109First, both developers and installers have the same basic user interface, i.e. 110the setup script. The difference is which Distutils *commands* they use: the 111:command:`sdist` command is almost exclusively for module developers, while 112:command:`install` is more often for installers (although most developers will 113want to install their own code occasionally). 114 115If you want to make things really easy for your users, you can create one or 116more built distributions for them. For instance, if you are running on a 117Windows machine, and want to make things easy for other Windows users, you can 118create an executable installer (the most appropriate type of built distribution 119for this platform) with the :command:`bdist_wininst` command. For example:: 120 121 python setup.py bdist_wininst 122 123will create an executable installer, :file:`foo-1.0.win32.exe`, in the current 124directory. 125 126Other useful built distribution formats are RPM, implemented by the 127:command:`bdist_rpm` command, Solaris :program:`pkgtool` 128(:command:`bdist_pkgtool`), and HP-UX :program:`swinstall` 129(:command:`bdist_sdux`). For example, the following command will create an RPM 130file called :file:`foo-1.0.noarch.rpm`:: 131 132 python setup.py bdist_rpm 133 134(The :command:`bdist_rpm` command uses the :command:`rpm` executable, therefore 135this has to be run on an RPM-based system such as Red Hat Linux, SuSE Linux, or 136Mandrake Linux.) 137 138You can find out what distribution formats are available at any time by running 139:: 140 141 python setup.py bdist --help-formats 142 143 144.. _python-terms: 145 146General Python terminology 147========================== 148 149If you're reading this document, you probably have a good idea of what modules, 150extensions, and so forth are. Nevertheless, just to be sure that everyone is 151operating from a common starting point, we offer the following glossary of 152common Python terms: 153 154module 155 the basic unit of code reusability in Python: a block of code imported by some 156 other code. Three types of modules concern us here: pure Python modules, 157 extension modules, and packages. 158 159pure Python module 160 a module written in Python and contained in a single :file:`.py` file (and 161 possibly associated :file:`.pyc` files). Sometimes referred to as a 162 "pure module." 163 164extension module 165 a module written in the low-level language of the Python implementation: C/C++ 166 for Python, Java for Jython. Typically contained in a single dynamically 167 loadable pre-compiled file, e.g. a shared object (:file:`.so`) file for Python 168 extensions on Unix, a DLL (given the :file:`.pyd` extension) for Python 169 extensions on Windows, or a Java class file for Jython extensions. (Note that 170 currently, the Distutils only handles C/C++ extensions for Python.) 171 172package 173 a module that contains other modules; typically contained in a directory in the 174 filesystem and distinguished from other directories by the presence of a file 175 :file:`__init__.py`. 176 177root package 178 the root of the hierarchy of packages. (This isn't really a package, since it 179 doesn't have an :file:`__init__.py` file. But we have to call it something.) 180 The vast majority of the standard library is in the root package, as are many 181 small, standalone third-party modules that don't belong to a larger module 182 collection. Unlike regular packages, modules in the root package can be found in 183 many directories: in fact, every directory listed in ``sys.path`` contributes 184 modules to the root package. 185 186 187.. _distutils-term: 188 189Distutils-specific terminology 190============================== 191 192The following terms apply more specifically to the domain of distributing Python 193modules using the Distutils: 194 195module distribution 196 a collection of Python modules distributed together as a single downloadable 197 resource and meant to be installed *en masse*. Examples of some well-known 198 module distributions are NumPy, SciPy, Pillow, 199 or mxBase. (This would be called a *package*, except that term is 200 already taken in the Python context: a single module distribution may contain 201 zero, one, or many Python packages.) 202 203pure module distribution 204 a module distribution that contains only pure Python modules and packages. 205 Sometimes referred to as a "pure distribution." 206 207non-pure module distribution 208 a module distribution that contains at least one extension module. Sometimes 209 referred to as a "non-pure distribution." 210 211distribution root 212 the top-level directory of your source tree (or source distribution); the 213 directory where :file:`setup.py` exists. Generally :file:`setup.py` will be 214 run from this directory. 215