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