mirror of
https://github.com/python/cpython.git
synced 2024-11-24 17:47:13 +01:00
d6abb72a79
svn+ssh://svn.python.org/python/branches/py3k ................ r77236 | georg.brandl | 2010-01-02 15:51:12 +0100 (Sa, 02 Jan 2010) | 1 line #7592: remove duplicate description. ................ r77383 | georg.brandl | 2010-01-09 10:48:46 +0100 (Sa, 09 Jan 2010) | 9 lines Merged revisions 77382 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ........ r77382 | georg.brandl | 2010-01-09 10:47:11 +0100 (Sa, 09 Jan 2010) | 1 line #7422: make it clear that getargspec() only works on Python functions. ........ ................ r77399 | georg.brandl | 2010-01-09 23:39:42 +0100 (Sa, 09 Jan 2010) | 1 line Remove redundant brackets in signatures. ................ r77857 | georg.brandl | 2010-01-30 18:54:04 +0100 (Sa, 30 Jan 2010) | 1 line #7814: fix wrong example function usage. ................ r78238 | georg.brandl | 2010-02-19 10:10:15 +0100 (Fr, 19 Feb 2010) | 1 line #5341: fix parenthesis placement. ................ r78861 | georg.brandl | 2010-03-12 11:04:37 +0100 (Fr, 12 Mär 2010) | 1 line Make tool compatible with 2.x and 3.x. ................ r78862 | georg.brandl | 2010-03-12 11:06:40 +0100 (Fr, 12 Mär 2010) | 13 lines Merged revisions 78859-78860 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ........ r78859 | georg.brandl | 2010-03-12 10:57:43 +0100 (Fr, 12 Mär 2010) | 1 line Get rid of backticks. ........ r78860 | georg.brandl | 2010-03-12 11:02:03 +0100 (Fr, 12 Mär 2010) | 1 line Fix warnings from "make check". ........ ................ r78958 | georg.brandl | 2010-03-14 11:51:01 +0100 (So, 14 Mär 2010) | 37 lines Merged revisions 78101,78115,78117,78182,78188,78245,78386,78496 via svnmerge from svn+ssh://pythondev@svn.python.org/python/trunk ........ r78101 | georg.brandl | 2010-02-08 01:04:54 +0100 (Mo, 08 Feb 2010) | 1 line Fix test_fnmatch. ........ r78115 | georg.brandl | 2010-02-08 23:40:51 +0100 (Mo, 08 Feb 2010) | 1 line Fix missing string formatting placeholder. ........ r78117 | georg.brandl | 2010-02-08 23:48:37 +0100 (Mo, 08 Feb 2010) | 1 line Convert test failure from output-producing to self.fail(). ........ r78182 | georg.brandl | 2010-02-14 09:18:23 +0100 (So, 14 Feb 2010) | 1 line #7926: fix stray parens. ........ r78188 | georg.brandl | 2010-02-14 14:38:12 +0100 (So, 14 Feb 2010) | 1 line #7926: fix-up wording. ........ r78245 | georg.brandl | 2010-02-19 20:36:08 +0100 (Fr, 19 Feb 2010) | 1 line #7967: PyXML is no more. ........ r78386 | georg.brandl | 2010-02-23 22:48:57 +0100 (Di, 23 Feb 2010) | 1 line #6544: fix refleak in kqueue, occurring in certain error conditions. ........ r78496 | georg.brandl | 2010-02-27 15:58:08 +0100 (Sa, 27 Feb 2010) | 1 line Link to http://www.python.org/dev/workflow/ from bugs page. ........ ................
294 lines
8.5 KiB
ReStructuredText
294 lines
8.5 KiB
ReStructuredText
.. _examples:
|
|
|
|
********
|
|
Examples
|
|
********
|
|
|
|
This chapter provides a number of basic examples to help get started with
|
|
distutils. Additional information about using distutils can be found in the
|
|
Distutils Cookbook.
|
|
|
|
|
|
.. seealso::
|
|
|
|
`Distutils Cookbook <http://wiki.python.org/moin/Distutils/Cookbook>`_
|
|
Collection of recipes showing how to achieve more control over distutils.
|
|
|
|
|
|
.. _pure-mod:
|
|
|
|
Pure Python distribution (by module)
|
|
====================================
|
|
|
|
If you're just distributing a couple of modules, especially if they don't live
|
|
in a particular package, you can specify them individually using the
|
|
:option:`py_modules` option in the setup script.
|
|
|
|
In the simplest case, you'll have two files to worry about: a setup script and
|
|
the single module you're distributing, :file:`foo.py` in this example::
|
|
|
|
<root>/
|
|
setup.py
|
|
foo.py
|
|
|
|
(In all diagrams in this section, *<root>* will refer to the distribution root
|
|
directory.) A minimal setup script to describe this situation would be::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foo',
|
|
version='1.0',
|
|
py_modules=['foo'],
|
|
)
|
|
|
|
Note that the name of the distribution is specified independently with the
|
|
:option:`name` option, and there's no rule that says it has to be the same as
|
|
the name of the sole module in the distribution (although that's probably a good
|
|
convention to follow). However, the distribution name is used to generate
|
|
filenames, so you should stick to letters, digits, underscores, and hyphens.
|
|
|
|
Since :option:`py_modules` is a list, you can of course specify multiple
|
|
modules, eg. if you're distributing modules :mod:`foo` and :mod:`bar`, your
|
|
setup might look like this::
|
|
|
|
<root>/
|
|
setup.py
|
|
foo.py
|
|
bar.py
|
|
|
|
and the setup script might be ::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
py_modules=['foo', 'bar'],
|
|
)
|
|
|
|
You can put module source files into another directory, but if you have enough
|
|
modules to do that, it's probably easier to specify modules by package rather
|
|
than listing them individually.
|
|
|
|
|
|
.. _pure-pkg:
|
|
|
|
Pure Python distribution (by package)
|
|
=====================================
|
|
|
|
If you have more than a couple of modules to distribute, especially if they are
|
|
in multiple packages, it's probably easier to specify whole packages rather than
|
|
individual modules. This works even if your modules are not in a package; you
|
|
can just tell the Distutils to process modules from the root package, and that
|
|
works the same as any other package (except that you don't have to have an
|
|
:file:`__init__.py` file).
|
|
|
|
The setup script from the last example could also be written as ::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
packages=[''],
|
|
)
|
|
|
|
(The empty string stands for the root package.)
|
|
|
|
If those two files are moved into a subdirectory, but remain in the root
|
|
package, e.g.::
|
|
|
|
<root>/
|
|
setup.py
|
|
src/ foo.py
|
|
bar.py
|
|
|
|
then you would still specify the root package, but you have to tell the
|
|
Distutils where source files in the root package live::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
package_dir={'': 'src'},
|
|
packages=[''],
|
|
)
|
|
|
|
More typically, though, you will want to distribute multiple modules in the same
|
|
package (or in sub-packages). For example, if the :mod:`foo` and :mod:`bar`
|
|
modules belong in package :mod:`foobar`, one way to layout your source tree is
|
|
::
|
|
|
|
<root>/
|
|
setup.py
|
|
foobar/
|
|
__init__.py
|
|
foo.py
|
|
bar.py
|
|
|
|
This is in fact the default layout expected by the Distutils, and the one that
|
|
requires the least work to describe in your setup script::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
packages=['foobar'],
|
|
)
|
|
|
|
If you want to put modules in directories not named for their package, then you
|
|
need to use the :option:`package_dir` option again. For example, if the
|
|
:file:`src` directory holds modules in the :mod:`foobar` package::
|
|
|
|
<root>/
|
|
setup.py
|
|
src/
|
|
__init__.py
|
|
foo.py
|
|
bar.py
|
|
|
|
an appropriate setup script would be ::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
package_dir={'foobar': 'src'},
|
|
packages=['foobar'],
|
|
)
|
|
|
|
Or, you might put modules from your main package right in the distribution
|
|
root::
|
|
|
|
<root>/
|
|
setup.py
|
|
__init__.py
|
|
foo.py
|
|
bar.py
|
|
|
|
in which case your setup script would be ::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
package_dir={'foobar': ''},
|
|
packages=['foobar'],
|
|
)
|
|
|
|
(The empty string also stands for the current directory.)
|
|
|
|
If you have sub-packages, they must be explicitly listed in :option:`packages`,
|
|
but any entries in :option:`package_dir` automatically extend to sub-packages.
|
|
(In other words, the Distutils does *not* scan your source tree, trying to
|
|
figure out which directories correspond to Python packages by looking for
|
|
:file:`__init__.py` files.) Thus, if the default layout grows a sub-package::
|
|
|
|
<root>/
|
|
setup.py
|
|
foobar/
|
|
__init__.py
|
|
foo.py
|
|
bar.py
|
|
subfoo/
|
|
__init__.py
|
|
blah.py
|
|
|
|
then the corresponding setup script would be ::
|
|
|
|
from distutils.core import setup
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
packages=['foobar', 'foobar.subfoo'],
|
|
)
|
|
|
|
(Again, the empty string in :option:`package_dir` stands for the current
|
|
directory.)
|
|
|
|
|
|
.. _single-ext:
|
|
|
|
Single extension module
|
|
=======================
|
|
|
|
Extension modules are specified using the :option:`ext_modules` option.
|
|
:option:`package_dir` has no effect on where extension source files are found;
|
|
it only affects the source for pure Python modules. The simplest case, a
|
|
single extension module in a single C source file, is::
|
|
|
|
<root>/
|
|
setup.py
|
|
foo.c
|
|
|
|
If the :mod:`foo` extension belongs in the root package, the setup script for
|
|
this could be ::
|
|
|
|
from distutils.core import setup
|
|
from distutils.extension import Extension
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
ext_modules=[Extension('foo', ['foo.c'])],
|
|
)
|
|
|
|
If the extension actually belongs in a package, say :mod:`foopkg`, then
|
|
|
|
With exactly the same source tree layout, this extension can be put in the
|
|
:mod:`foopkg` package simply by changing the name of the extension::
|
|
|
|
from distutils.core import setup
|
|
from distutils.extension import Extension
|
|
setup(name='foobar',
|
|
version='1.0',
|
|
ext_modules=[Extension('foopkg.foo', ['foo.c'])],
|
|
)
|
|
|
|
Checking a package
|
|
==================
|
|
|
|
The ``check`` command allows you to verify if your package meta-data
|
|
meet the minimum requirements to build a distribution.
|
|
|
|
To run it, just call it using your :file:`setup.py` script. If something is
|
|
missing, ``check`` will display a warning.
|
|
|
|
Let's take an example with a simple script::
|
|
|
|
from distutils.core import setup
|
|
|
|
setup(name='foobar')
|
|
|
|
Running the ``check`` command will display some warnings::
|
|
|
|
$ python setup.py check
|
|
running check
|
|
warning: check: missing required meta-data: version, url
|
|
warning: check: missing meta-data: either (author and author_email) or
|
|
(maintainer and maintainer_email) must be supplied
|
|
|
|
|
|
If you use the reStructuredText syntax in the ``long_description`` field and
|
|
`docutils <http://docutils.sourceforge.net/>`_ is installed you can check if
|
|
the syntax is fine with the ``check`` command, using the ``restructuredtext``
|
|
option.
|
|
|
|
For example, if the :file:`setup.py` script is changed like this::
|
|
|
|
from distutils.core import setup
|
|
|
|
desc = """\
|
|
My description
|
|
=============
|
|
|
|
This is the description of the ``foobar`` package.
|
|
"""
|
|
|
|
setup(name='foobar', version='1', author='tarek',
|
|
author_email='tarek@ziade.org',
|
|
url='http://example.com', long_description=desc)
|
|
|
|
Where the long description is broken, ``check`` will be able to detect it
|
|
by using the :mod:`docutils` parser::
|
|
|
|
$ pythontrunk setup.py check --restructuredtext
|
|
running check
|
|
warning: check: Title underline too short. (line 2)
|
|
warning: check: Could not finish the parsing.
|
|
|
|
.. % \section{Multiple extension modules}
|
|
.. % \label{multiple-ext}
|
|
|
|
.. % \section{Putting it all together}
|
|
|
|
|