7. 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.

lihat juga

Distutils Cookbook: Collection of recipes showing how to achieve more control over distutils.

7.1. 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 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, 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 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 py_modules is a list, you can of course specify multiple modules, eg. if you're distributing modules foo and 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.

7.2. 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 __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 foo and bar modules belong in package 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 package_dir option again. For example, if the src directory holds modules in the 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 packages, but any entries in 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 __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'],
      )

7.3. Single extension module¶

Extension modules are specified using the ext_modules 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 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 foopkg, then

With exactly the same source tree layout, this extension can be put in the 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'])],
      )

7.4. 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 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 is installed you can check if the syntax is fine with the check command, using the restructuredtext option.

For example, if the 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 docutils parser:

$ python setup.py check --restructuredtext
running check
warning: check: Title underline too short. (line 2)
warning: check: Could not finish the parsing.

7.5. Reading the metadata¶

The distutils.core.setup() function provides a command-line interface that allows you to query the metadata fields of a project through the setup.py script of a given project:

$ python setup.py --name
distribute

This call reads the name metadata by running the distutils.core.setup() function. Although, when a source or binary distribution is created with Distutils, the metadata fields are written in a static file called PKG-INFO. When a Distutils-based project is installed in Python, the PKG-INFO file is copied alongside the modules and packages of the distribution under NAME-VERSION-pyX.X.egg-info, where NAME is the name of the project, VERSION its version as defined in the Metadata, and pyX.X the major and minor version of Python like 2.7 or 3.2.

You can read back this static file, by using the distutils.dist.DistributionMetadata class and its read_pkg_file() method:

>>> from distutils.dist import DistributionMetadata
>>> metadata = DistributionMetadata()
>>> metadata.read_pkg_file(open('distribute-0.6.8-py2.7.egg-info'))
>>> metadata.name
'distribute'
>>> metadata.version
'0.6.8'
>>> metadata.description
'Easily download, build, install, upgrade, and uninstall Python packages'

Notice that the class can also be instantiated with a metadata file path to loads its values:

>>> pkg_info_path = 'distribute-0.6.8-py2.7.egg-info'
>>> DistributionMetadata(pkg_info_path).name
'distribute'

7. Examples¶

7.1. Pure Python distribution (by module)¶

7.2. Pure Python distribution (by package)¶

7.3. Single extension module¶

7.4. Checking a package¶

7.5. Reading the metadata¶

Table of Contents

Topik sebelum

Topik berikutnya

Halaman Ini