Éric Araujo | 3a9f58f | 2011-06-01 20:42:49 +0200 | [diff] [blame] | 1 | .. _packaging-built-dist: |
| 2 | |
| 3 | **************************** |
| 4 | Creating Built Distributions |
| 5 | **************************** |
| 6 | |
| 7 | A "built distribution" is what you're probably used to thinking of either as a |
| 8 | "binary package" or an "installer" (depending on your background). It's not |
| 9 | necessarily binary, though, because it might contain only Python source code |
| 10 | and/or byte-code; and we don't call it a package, because that word is already |
| 11 | spoken for in Python. (And "installer" is a term specific to the world of |
| 12 | mainstream desktop systems.) |
| 13 | |
| 14 | A built distribution is how you make life as easy as possible for installers of |
| 15 | your module distribution: for users of RPM-based Linux systems, it's a binary |
| 16 | RPM; for Windows users, it's an executable installer; for Debian-based Linux |
| 17 | users, it's a Debian package; and so forth. Obviously, no one person will be |
| 18 | able to create built distributions for every platform under the sun, so the |
| 19 | Distutils are designed to enable module developers to concentrate on their |
| 20 | specialty---writing code and creating source distributions---while an |
| 21 | intermediary species called *packagers* springs up to turn source distributions |
| 22 | into built distributions for as many platforms as there are packagers. |
| 23 | |
| 24 | Of course, the module developer could be his own packager; or the packager could |
| 25 | be a volunteer "out there" somewhere who has access to a platform which the |
| 26 | original developer does not; or it could be software periodically grabbing new |
| 27 | source distributions and turning them into built distributions for as many |
| 28 | platforms as the software has access to. Regardless of who they are, a packager |
| 29 | uses the setup script and the :command:`bdist` command family to generate built |
| 30 | distributions. |
| 31 | |
| 32 | As a simple example, if I run the following command in the Distutils source |
| 33 | tree:: |
| 34 | |
| 35 | python setup.py bdist |
| 36 | |
| 37 | then the Distutils builds my module distribution (the Distutils itself in this |
| 38 | case), does a "fake" installation (also in the :file:`build` directory), and |
| 39 | creates the default type of built distribution for my platform. The default |
| 40 | format for built distributions is a "dumb" tar file on Unix, and a simple |
| 41 | executable installer on Windows. (That tar file is considered "dumb" because it |
| 42 | has to be unpacked in a specific location to work.) |
| 43 | |
| 44 | Thus, the above command on a Unix system creates |
| 45 | :file:`Distutils-1.0.{plat}.tar.gz`; unpacking this tarball from the right place |
| 46 | installs the Distutils just as though you had downloaded the source distribution |
| 47 | and run ``python setup.py install``. (The "right place" is either the root of |
| 48 | the filesystem or Python's :file:`{prefix}` directory, depending on the options |
| 49 | given to the :command:`bdist_dumb` command; the default is to make dumb |
| 50 | distributions relative to :file:`{prefix}`.) |
| 51 | |
| 52 | Obviously, for pure Python distributions, this isn't any simpler than just |
| 53 | running ``python setup.py install``\ ---but for non-pure distributions, which |
| 54 | include extensions that would need to be compiled, it can mean the difference |
| 55 | between someone being able to use your extensions or not. And creating "smart" |
| 56 | built distributions, such as an executable installer for |
| 57 | Windows, is far more convenient for users even if your distribution doesn't |
| 58 | include any extensions. |
| 59 | |
| 60 | The :command:`bdist` command has a :option:`--formats` option, similar to the |
| 61 | :command:`sdist` command, which you can use to select the types of built |
| 62 | distribution to generate: for example, :: |
| 63 | |
| 64 | python setup.py bdist --format=zip |
| 65 | |
| 66 | would, when run on a Unix system, create :file:`Distutils-1.0.{plat}.zip`\ |
| 67 | ---again, this archive would be unpacked from the root directory to install the |
| 68 | Distutils. |
| 69 | |
| 70 | The available formats for built distributions are: |
| 71 | |
| 72 | +-------------+------------------------------+---------+ |
| 73 | | Format | Description | Notes | |
| 74 | +=============+==============================+=========+ |
| 75 | | ``gztar`` | gzipped tar file | (1),(3) | |
| 76 | | | (:file:`.tar.gz`) | | |
| 77 | +-------------+------------------------------+---------+ |
Éric Araujo | 3a9f58f | 2011-06-01 20:42:49 +0200 | [diff] [blame] | 78 | | ``tar`` | tar file (:file:`.tar`) | \(3) | |
| 79 | +-------------+------------------------------+---------+ |
| 80 | | ``zip`` | zip file (:file:`.zip`) | (2),(4) | |
| 81 | +-------------+------------------------------+---------+ |
| 82 | | ``wininst`` | self-extracting ZIP file for | \(4) | |
| 83 | | | Windows | | |
| 84 | +-------------+------------------------------+---------+ |
| 85 | | ``msi`` | Microsoft Installer. | | |
| 86 | +-------------+------------------------------+---------+ |
| 87 | |
| 88 | |
| 89 | Notes: |
| 90 | |
| 91 | (1) |
| 92 | default on Unix |
| 93 | |
| 94 | (2) |
| 95 | default on Windows |
| 96 | |
| 97 | (3) |
Éric Araujo | 83ab3f3 | 2011-08-30 01:19:02 +0200 | [diff] [blame] | 98 | requires external utilities: :program:`tar` and possibly one of :program:`gzip` |
| 99 | or :program:`bzip2` |
Éric Araujo | 3a9f58f | 2011-06-01 20:42:49 +0200 | [diff] [blame] | 100 | |
| 101 | (4) |
| 102 | requires either external :program:`zip` utility or :mod:`zipfile` module (part |
| 103 | of the standard Python library since Python 1.6) |
| 104 | |
| 105 | You don't have to use the :command:`bdist` command with the :option:`--formats` |
| 106 | option; you can also use the command that directly implements the format you're |
| 107 | interested in. Some of these :command:`bdist` "sub-commands" actually generate |
| 108 | several similar formats; for instance, the :command:`bdist_dumb` command |
Éric Araujo | 83ab3f3 | 2011-08-30 01:19:02 +0200 | [diff] [blame] | 109 | generates all the "dumb" archive formats (``tar``, ``gztar``, and |
Éric Araujo | 3a9f58f | 2011-06-01 20:42:49 +0200 | [diff] [blame] | 110 | ``zip``). The :command:`bdist` sub-commands, and the formats generated by |
| 111 | each, are: |
| 112 | |
| 113 | +--------------------------+-----------------------+ |
| 114 | | Command | Formats | |
| 115 | +==========================+=======================+ |
Éric Araujo | 83ab3f3 | 2011-08-30 01:19:02 +0200 | [diff] [blame] | 116 | | :command:`bdist_dumb` | tar, gztar, zip | |
Éric Araujo | 3a9f58f | 2011-06-01 20:42:49 +0200 | [diff] [blame] | 117 | +--------------------------+-----------------------+ |
| 118 | | :command:`bdist_wininst` | wininst | |
| 119 | +--------------------------+-----------------------+ |
| 120 | | :command:`bdist_msi` | msi | |
| 121 | +--------------------------+-----------------------+ |
| 122 | |
| 123 | The following sections give details on the individual :command:`bdist_\*` |
| 124 | commands. |
| 125 | |
| 126 | |
| 127 | .. _packaging-creating-dumb: |
| 128 | |
| 129 | Creating dumb built distributions |
| 130 | ================================= |
| 131 | |
| 132 | .. XXX Need to document absolute vs. prefix-relative packages here, but first |
| 133 | I have to implement it! |
| 134 | |
| 135 | |
| 136 | .. _packaging-creating-wininst: |
| 137 | |
| 138 | Creating Windows Installers |
| 139 | =========================== |
| 140 | |
| 141 | Executable installers are the natural format for binary distributions on |
| 142 | Windows. They display a nice graphical user interface, display some information |
| 143 | about the module distribution to be installed taken from the metadata in the |
| 144 | setup script, let the user select a few options, and start or cancel the |
| 145 | installation. |
| 146 | |
| 147 | Since the metadata is taken from the setup script, creating Windows installers |
| 148 | is usually as easy as running:: |
| 149 | |
| 150 | python setup.py bdist_wininst |
| 151 | |
| 152 | or the :command:`bdist` command with the :option:`--formats` option:: |
| 153 | |
| 154 | python setup.py bdist --formats=wininst |
| 155 | |
| 156 | If you have a pure module distribution (only containing pure Python modules and |
| 157 | packages), the resulting installer will be version independent and have a name |
| 158 | like :file:`foo-1.0.win32.exe`. These installers can even be created on Unix |
| 159 | platforms or Mac OS X. |
| 160 | |
| 161 | If you have a non-pure distribution, the extensions can only be created on a |
| 162 | Windows platform, and will be Python version dependent. The installer filename |
| 163 | will reflect this and now has the form :file:`foo-1.0.win32-py2.0.exe`. You |
| 164 | have to create a separate installer for every Python version you want to |
| 165 | support. |
| 166 | |
Éric Araujo | 8808015 | 2011-11-03 05:08:28 +0100 | [diff] [blame^] | 167 | The installer will try to compile pure modules into :term:`bytecode` after installation |
Éric Araujo | 3a9f58f | 2011-06-01 20:42:49 +0200 | [diff] [blame] | 168 | on the target system in normal and optimizing mode. If you don't want this to |
| 169 | happen for some reason, you can run the :command:`bdist_wininst` command with |
| 170 | the :option:`--no-target-compile` and/or the :option:`--no-target-optimize` |
| 171 | option. |
| 172 | |
| 173 | By default the installer will display the cool "Python Powered" logo when it is |
| 174 | run, but you can also supply your own 152x261 bitmap which must be a Windows |
| 175 | :file:`.bmp` file with the :option:`--bitmap` option. |
| 176 | |
| 177 | The installer will also display a large title on the desktop background window |
| 178 | when it is run, which is constructed from the name of your distribution and the |
| 179 | version number. This can be changed to another text by using the |
| 180 | :option:`--title` option. |
| 181 | |
| 182 | The installer file will be written to the "distribution directory" --- normally |
| 183 | :file:`dist/`, but customizable with the :option:`--dist-dir` option. |
| 184 | |
| 185 | .. _packaging-cross-compile-windows: |
| 186 | |
| 187 | Cross-compiling on Windows |
| 188 | ========================== |
| 189 | |
| 190 | Starting with Python 2.6, packaging is capable of cross-compiling between |
| 191 | Windows platforms. In practice, this means that with the correct tools |
| 192 | installed, you can use a 32bit version of Windows to create 64bit extensions |
| 193 | and vice-versa. |
| 194 | |
| 195 | To build for an alternate platform, specify the :option:`--plat-name` option |
| 196 | to the build command. Valid values are currently 'win32', 'win-amd64' and |
| 197 | 'win-ia64'. For example, on a 32bit version of Windows, you could execute:: |
| 198 | |
| 199 | python setup.py build --plat-name=win-amd64 |
| 200 | |
| 201 | to build a 64bit version of your extension. The Windows Installers also |
| 202 | support this option, so the command:: |
| 203 | |
| 204 | python setup.py build --plat-name=win-amd64 bdist_wininst |
| 205 | |
| 206 | would create a 64bit installation executable on your 32bit version of Windows. |
| 207 | |
| 208 | To cross-compile, you must download the Python source code and cross-compile |
| 209 | Python itself for the platform you are targetting - it is not possible from a |
| 210 | binary installtion of Python (as the .lib etc file for other platforms are |
| 211 | not included.) In practice, this means the user of a 32 bit operating |
| 212 | system will need to use Visual Studio 2008 to open the |
| 213 | :file:`PCBuild/PCbuild.sln` solution in the Python source tree and build the |
| 214 | "x64" configuration of the 'pythoncore' project before cross-compiling |
| 215 | extensions is possible. |
| 216 | |
| 217 | Note that by default, Visual Studio 2008 does not install 64bit compilers or |
| 218 | tools. You may need to reexecute the Visual Studio setup process and select |
| 219 | these tools (using Control Panel->[Add/Remove] Programs is a convenient way to |
| 220 | check or modify your existing install.) |
| 221 | |
| 222 | .. _packaging-postinstallation-script: |
| 223 | |
| 224 | The Postinstallation script |
| 225 | --------------------------- |
| 226 | |
| 227 | Starting with Python 2.3, a postinstallation script can be specified with the |
| 228 | :option:`--install-script` option. The basename of the script must be |
| 229 | specified, and the script filename must also be listed in the scripts argument |
| 230 | to the setup function. |
| 231 | |
| 232 | This script will be run at installation time on the target system after all the |
| 233 | files have been copied, with ``argv[1]`` set to :option:`-install`, and again at |
| 234 | uninstallation time before the files are removed with ``argv[1]`` set to |
| 235 | :option:`-remove`. |
| 236 | |
| 237 | The installation script runs embedded in the windows installer, every output |
| 238 | (``sys.stdout``, ``sys.stderr``) is redirected into a buffer and will be |
| 239 | displayed in the GUI after the script has finished. |
| 240 | |
| 241 | Some functions especially useful in this context are available as additional |
| 242 | built-in functions in the installation script. |
| 243 | |
| 244 | .. currentmodule:: bdist_wininst-postinst-script |
| 245 | |
| 246 | .. function:: directory_created(path) |
| 247 | file_created(path) |
| 248 | |
| 249 | These functions should be called when a directory or file is created by the |
| 250 | postinstall script at installation time. It will register *path* with the |
| 251 | uninstaller, so that it will be removed when the distribution is uninstalled. |
| 252 | To be safe, directories are only removed if they are empty. |
| 253 | |
| 254 | |
| 255 | .. function:: get_special_folder_path(csidl_string) |
| 256 | |
| 257 | This function can be used to retrieve special folder locations on Windows like |
| 258 | the Start Menu or the Desktop. It returns the full path to the folder. |
| 259 | *csidl_string* must be one of the following strings:: |
| 260 | |
| 261 | "CSIDL_APPDATA" |
| 262 | |
| 263 | "CSIDL_COMMON_STARTMENU" |
| 264 | "CSIDL_STARTMENU" |
| 265 | |
| 266 | "CSIDL_COMMON_DESKTOPDIRECTORY" |
| 267 | "CSIDL_DESKTOPDIRECTORY" |
| 268 | |
| 269 | "CSIDL_COMMON_STARTUP" |
| 270 | "CSIDL_STARTUP" |
| 271 | |
| 272 | "CSIDL_COMMON_PROGRAMS" |
| 273 | "CSIDL_PROGRAMS" |
| 274 | |
| 275 | "CSIDL_FONTS" |
| 276 | |
| 277 | If the folder cannot be retrieved, :exc:`OSError` is raised. |
| 278 | |
| 279 | Which folders are available depends on the exact Windows version, and probably |
| 280 | also the configuration. For details refer to Microsoft's documentation of the |
Georg Brandl | d3b41c6 | 2011-07-09 11:48:50 +0200 | [diff] [blame] | 281 | :c:func:`SHGetSpecialFolderPath` function. |
Éric Araujo | 3a9f58f | 2011-06-01 20:42:49 +0200 | [diff] [blame] | 282 | |
| 283 | |
| 284 | .. function:: create_shortcut(target, description, filename[, arguments[, workdir[, iconpath[, iconindex]]]]) |
| 285 | |
| 286 | This function creates a shortcut. *target* is the path to the program to be |
| 287 | started by the shortcut. *description* is the description of the shortcut. |
| 288 | *filename* is the title of the shortcut that the user will see. *arguments* |
| 289 | specifies the command-line arguments, if any. *workdir* is the working directory |
| 290 | for the program. *iconpath* is the file containing the icon for the shortcut, |
| 291 | and *iconindex* is the index of the icon in the file *iconpath*. Again, for |
| 292 | details consult the Microsoft documentation for the :class:`IShellLink` |
| 293 | interface. |
| 294 | |
| 295 | |
| 296 | Vista User Access Control (UAC) |
| 297 | =============================== |
| 298 | |
| 299 | Starting with Python 2.6, bdist_wininst supports a :option:`--user-access-control` |
| 300 | option. The default is 'none' (meaning no UAC handling is done), and other |
| 301 | valid values are 'auto' (meaning prompt for UAC elevation if Python was |
| 302 | installed for all users) and 'force' (meaning always prompt for elevation). |