You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

214 lines
8.4 KiB

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