Reference resources Python Of Distutils modular - cloud + Community - Tencent cloud
Catalog
One 、Distutils brief introduction
1.1、 Concepts and terms
1.2、 A simple example
1.3、 Basic terminology
1.4、Distutils The term
Two 、 To write setup Script
2.1、 List entire package
2.2、 List the individual modules
2.3、 Extension module
2.3.1、 Extensions and packages
2.3.2、 Extended source file
2.3.3、 The other options
2.4、 The relationship between release and package
2.5、 set up script
2.6、 install package data
2.7、 Install other files
2.8、 Metadata
2.9、 debugging setup Script
3、 ... and 、 The configuration file
Four 、 Source code release
4.1、 Specify the published file
4.2、Manifest Related options
4.3、MANIFEST.in Templates
5、 ... and 、 Build release （Built Distributions）
6、 ... and 、Distutils And PYPI
7、 ... and 、 A simple example
7.1、 pure Python Release （ package ）
7.3、 Separate expansion modules
8、 ... and 、 other
Distutils Can be used in Python Build and install additional modules in the environment . The new module can be pure Python Of , It can also be used C/C++ Write extension module , Or it could be Python package , The package contains C and Python Write modules .
For module developers and users who need to install modules ,Distutils It's easy to use , As a developer , In addition to writing the source code , It also needs to be ：
Some module developers do not consider multiple platform releases when developing , So there it is packagers Role , They get the source code release from the module developer , Then build on multiple platforms , And release build versions of multiple platforms .
from python Compiling setup Scripts are usually very simple . As autoconf Type of configuration script ,setup Scripts can be run multiple times when building and installing a module release . such as , If you need to release a file called foo Module , It is contained in a file foo.py, that setup The script can be written like this ：
from distutils.core import setup
setup(name='foo',
version='1.0',
py_modules=['foo'],
) setup The parameter representation of the function is provided to Distutils Information about , These parameters fall into two categories ： The metadata of the package （ Package name 、 Version number ） And package information （ In this case is a Python List of modules ）; Modules are represented by module names , Not the file name （ The same is true for packages and extensions ）; It is suggested that more metadata can be provided , Like your name ,email Address and project URL Address . Write it well setup.py after , You can create the source code of the module and publish it ：
python setup.py sdist about Windows for , The order is ：
setup.py sdistsdist The command creates a archive file （ such as Unix Upper tar file ,Windows Upper zip file ）, It contains setup.py, foo.py. The archive The file is named foo-1.0.tar.gz(zip), The directory name after decompression is foo-1.0. If a user wants to install foo modular , He just needs to download foo-1.0.tar.gz, decompression , Get into foo-1.0 Catalog , And then run ：
python setup.py install This command will eventually foo.py Copied to the Python The environment is stored in the directory of the third-party module . stay linux In the environment , The output of running this command is ：
# python setup.py install
running install
running build
running build_py
creating build
creating build/lib
copying foo.py -> build/lib
running install_lib
copying build/lib/foo.py -> /usr/lib/python2.7/site-packages
byte-compiling /usr/lib/python2.7/site-packages/foo.py to foo.pyc
running install_egg_info
Writing /usr/lib/python2.7/site-packages/foo-1.0-py2.7.egg-info The file generated by this command is ：
/usr/lib/python2.7/site-packages/foo-1.0-py2.7.egg-info
/usr/lib/python2.7/site-packages/foo.py
/usr/lib/python2.7/site-packages/foo.pyc
This simple example shows Distutils Basic concepts of . First of all , Developers and installers have the same user interface , That is to say setup Script , But they use Distutils Different commands ,sdist Commands are almost exclusively used by developers , and install More commonly used by installers . If you want users to use as simple as possible , You can create multiple build releases . such as , If in Windows in , have access to bdist_wininst Command to create a exe The installation files , The following command will create... In the current directory foo-1.0.win32.exe file ：
python setup.py bdist_wininst Other build releases are RPM（ from bdist_rpm Command implementation ）,Solaris pkgtool（bdist_pkgtool）, as well as HP-UX swinstall (bdist_sdux). such as , The following command will create RPM file foo-1.0.noarch.rpm（bdist_rpm The command must be run based on RPM The system of , such as Red Hat Linux, SuSE Linux, Mandrake Linux）：
python setup.py bdist_rpmYou can get the currently supported publishing formats through the following command ：
python setup.py bdist --help-formatssetup Scripts are using Distutils structure 、 Release and install the core of the module .setup The role of the script is to Distutils Describe the information of the publishing module . From the simple example above, we can see ,setup The script mainly calls setup function , And the module developers are going to Distutils Most of the module information provided is provided by setup Provided by the keyword parameter of the function . Here is a more advanced example ：Distutils Of the module itself setup Script ：
setup(name='Distutils',
version='1.0',
description='Python Distribution Utilities',
author='Greg Ward',
author_email='[email protected]',
url='https://www.python.org/sigs/distutils-sig/',
packages=['distutils', 'distutils.command'],
) The above script has more metadata , Two packages are listed （packages）, Instead of listing each module . because Distutils Contains multiple modules , These modules are divided into two packages ; Listing all the modules is tedious and difficult to maintain . Be careful , stay setup The path in the script must begin with Unix Form to write , That is, by ”/” Segmented .Distutils Before using these paths , Transform this representation into a format that is appropriate for the current platform .
Setup Functional packages The parameter is a list , Which includes Distutils Need to deal with （ structure 、 Release 、 Installation, etc ） All the bags of . To achieve this , Then the package name and directory name must correspond to each other , For example, the package name is distutils, It means in the root directory of the release （setup Script directory ） There is distutils subdirectories ; Another example is in setup Script packages = ['foo'], Means to be in setup The corresponding... Exists in the directory where the script is located foo Contents and foo/__init__.py file . For example if setup The script is as follows ：
setup(name='foo',
version='1.0',
packages = ['foo']
) and setup The directory where the script is located does not foo Catalog （ only one setup.py Script ）, It's executing python setup.py bdist On command , The following error will be printed ：
error: package directory 'foo' does not exist If you create foo Catalog , But no foo/__init__.py file , be Distutils The following warning will be generated , But the package will still be processed ：
package init file 'foo/__init__.py' not found (or not a regular file) have access to package_dir Option to change the default correspondence rule .package_dir It's a dictionary , Among them key Is the name of the package to install , If it is empty , It means root package,value This is the bag （key） The directory of the corresponding source tree . For example if setup.py The contents are as follows ：
setup(name='foo',
version='1.0',
package_dir = {'':'lib'},
packages = ['foo']
) Must exist in the directory lib subdirectories ,lib/foo subdirectories , And documents lib/foo/__init__.py. So the source tree is as follows ：
setup.py
lib/
foo/
__init__.py
foo.py
The last generated file is ：
\usr\local\lib\python2.7\dist-packages\ foo-1.0.egg-info
\usr\local\lib\python2.7\dist-packages\foo\__init__.py
\usr\local\lib\python2.7\dist-packages\foo\__init__.pyc
\usr\local\lib\python2.7\dist-packages\foo\foo.py
\usr\local\lib\python2.7\dist-packages\foo\foo.pyc
Another example ,foo Package correspondence lib Catalog , therefore ,foo.bar The package corresponds to lib/bar subdirectories . So if setup.py That's what it says in ：
package_dir = {'foo':'lib'},
packages = ['foo',’foo.bar’] There must be lib/__init__.py, lib/bar/__init__.py file . The source tree is as follows ：
setup.py
lib/
__init__.py
foo.py
bar/
__init__.py
bar.py
The last generated file is ：
\usr\local\lib\python2.7\dist-packages\ foo-1.0.egg-info
\usr\local\lib\python2.7\dist-packages\foo\__init__.py
\usr\local\lib\python2.7\dist-packages\foo\__init__.pyc
\usr\local\lib\python2.7\dist-packages\foo\foo.py
\usr\local\lib\python2.7\dist-packages\foo\foo.pyc
\usr\local\lib\python2.7\dist-packages\foo\bar\__init__.py
\usr\local\lib\python2.7\dist-packages\foo\bar\__init__.pyc
\usr\local\lib\python2.7\dist-packages\foo\bar\bar.py
\usr\local\lib\python2.7\dist-packages\foo\bar\bar.pyc
If the release contains only a few modules , You might prefer to list all the modules , Instead of listing packages , Especially in root package There is a single module in the （ Or there is no bag at all ）. have access to py_modules Parameters , Take the following example ：
setup(name='foo',
version='1.0',
py_modules = ['mod1', 'pkg.mod2']
) It describes two modules , In a root package in , The other is pkg In bag . According to the default package / Directory correspondence rules , These two modules exist in the file mod1.py and pkg/mod2.py in , And must exist pkg/__init__.py file （ If it doesn't exist , An alarm will be generated ：package init file 'pkg/__init__.py' not found (or not a regular file)）. Of course , You can also use package_dir Option to change this correspondence . therefore , The source tree is as follows ：
setup.py
mod1.py
pkg/
__init__.py
mod2.py
The resulting file is ：
\usr\local\lib\python2.7\dist-packages\foo-1.0.egg-info
\usr\local\lib\python2.7\dist-packages\mod1.py
\usr\local\lib\python2.7\dist-packages\mod1.pyc
\usr\local\lib\python2.7\dist-packages\pkg\__init__.py
\usr\local\lib\python2.7\dist-packages\pkg\__init__.pyc
\usr\local\lib\python2.7\dist-packages\pkg\mod2.py
\usr\local\lib\python2.7\dist-packages\pkg\mod2.pyc
stay Distutils The extension module described in is more pure python The modules are more complex . For pure python modular , Just list the modules or packages , then Distutils Will find the right documents , This is not enough for extension modules , You also need to specify the extension 、 Source files and other compilers / Link required parameters （ Directories to include , Libraries that need to be connected, etc ）. Description extension modules can be setup Function's key argument ext_modules Realization .ext_modules yes Extension List of instances , every last Extension An example describes an independent extension module . For example, the release contains an independent extension module called foo, from foo.c Realization , And no other compile link instructions are required , Then the following statement can describe the extension module ：
Extension('foo', ['foo.c']) Extension It can be downloaded from distutils.core Middle follow setup Let's introduce . therefore , For a release that contains only one extension module ,setup The script is as follows ：
from distutils.core import setup, Extension
setup(name='foo',
version='1.0',
ext_modules=[Extension('foo', ['foo.c'])],
) The underlying extension build mechanism is made up of build_ext Command implemented .Extension Class in description Python It has great flexibility when expanding .
Usually ,Extension The first argument to the constructor of a class is the name of the extension , Take the following statement ：
Extension('foo', ['src/foo1.c', 'src/foo2.c']) If you execute python setup.py bdist, The corresponding compiler and connector commands will be called , Finally, according to the generated foo.so file , Stored in the root directory of the release package , The resulting file is ：
\usr\local\lib\python2.7\dist-packages\foo.so
\usr\local\lib\python2.7\dist-packages\foo-1.0.egg-infoAnother example is the following statement ：
Extension('pkg.foo', ['src/foo1.c', 'src/foo2.c']) The source files used are the same , The final generated result file is the same foo.so, The only difference is the directory where the final result file is stored , It is under the root directory of the release package pkg Under the table of contents . So the resulting file is ：
\usr\local\lib\python2.7\dist-packages\pkg\foo.so
\usr\local\lib\python2.7\dist-packages\foo-1.0.egg-info
If there are multiple extensions under a package , And put these extensions in a unified directory , You can use ext_package keyword , Take the following statement ：
setup(...,
ext_package='pkg',
ext_modules=[Extension('foo', ['src/foo.c']),
Extension('subpkg.bar', ['src/bar.c'])]
) The above description will compile src/foo.c by pkg.foo, take src/bar.c Compiled into pkg.subpkg.bar. So the source tree is as follows ：
setup.py
src/
foo.c
bar.c
The resulting file is ：
\usr\local\lib\python2.7\dist-packages\foo-1.0.egg-info
\usr\local\lib\python2.7\dist-packages\pkg\foo.so
\usr\local\lib\python2.7\dist-packages\pkg\subpkg\bar.so
Extension The second argument to the build function is the list of source files . at present Distutils Support only C、C++ and Objective-C Expand , So these source files are C、C++ and Objective-C Source file .（C++ The extension of the source file can be .cc and .cpp,Unix and Windows Compilers support ）. However, you can also include... In the list SWIG Interface file （.i file ）,build_ext The command knows how to handle SWIG Interface file . Although an alarm will occur , But it can be delivered like this SWIG Options ：
setup(...,
ext_modules=[Extension('_foo', ['foo.i'],
swig_opts=['-modern', '-I../include'])],
py_modules=['foo'],
) Or use the following command ：
> python setup.py build_ext --swig-opts="-modern -I../include" On some systems , The list can also contain non source files that can be processed by the compiler . Currently only supported Windows message text file （.mc） and Visual C++ Resource definition file for （.rc）. They will be compiled into binary files .res And link to the executable file .
Extension You can also specify other options , For example, you can specify the header file directory ,define or undefine macro 、 Libraries that need to be linked , Link time and runtime search paths to libraries, and so on . Please refer to ：
https://docs.python.org/2/distutils/setupscript.html#preprocessor-options
https://docs.python.org/2/distutils/setupscript.html#library-options
https://docs.python.org/2/distutils/setupscript.html#other-options
There are three relationships between release and package ： It relies on other packages , It serves other packages , It eliminates other packages . These relationships can be used separately setup The parameters of the function requires ,provides and obsoletes To specify the , Specific reference ：https://docs.python.org/2/distutils/setupscript.html#relationships-between-distributions-and-packages.
Modules usually do not run themselves , It is introduced by the script . In addition to modules that can be installed , You can also install scripts that can be run directly , Specific reference https://docs.python.org/2/distutils/setupscript.html#installing-scripts.
Sometimes other files need to be installed in the package , These files are closely related to the implementation of the package , Or a text file containing document information , These files are called package data. Use setup Function package_data Parameters can be added to packages Add package data. The value of this parameter must be a dictionary , Dictionary key Namely package name,value It's a list, It contains the information that needs to be copied to package A series of paths in . These paths are relative to the package directory （ such as package_dir）, therefore , These files must exist in the source directory of the package . At the time of installation , The corresponding directory will also be created . such as , If the package has a subdirectory containing data files , The source tree is as follows ：
setup.py
src/
mypkg/
__init__.py
module.py
data/
tables.dat
spoons.dat
forks.dat
Corresponding setup The function can be written like this ：
setup(...,
packages=['mypkg'],
package_dir={'mypkg': 'src/mypkg'},
package_data={'mypkg': ['data/*.dat']},
)
Can pass data_files Option to install files other than those mentioned above , Such as configuration files , Data files, etc .data_files It's a list , The elements in the list are (directory, files), such as ：
setup(...,
data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']),
('config', ['cfg/data.cfg']),
('/etc/init.d', ['init-script'])]
) (directory, files) in ,directory Indicates where the file will eventually be installed , If it is a relative path , Relative to installation prefix for （ For pure python In terms of package , Namely sys.prefix; For expansion packs , It is sys.exec_prefix）.files Is the file to install , The directory information （ Before the installation ） Is relative to setup.py In terms of the directory , When installing ,setup.py according to files Information found in the file , Then install it to directory in .
Setup Scripts can contain a lot of published metadata , Such as the name 、 edition 、 Author, etc , Specific lists and notes , Refer to the https://docs.python.org/2/distutils/setupscript.html#additional-meta-data
If it's running setup An error occurred in the script , be Distutils Will print out a simple error message , For developers, these error messages may not be enough to find the cause of the error . So you can set the environment variable DISTUTILS_DEBUG, Set it to any value （ It cannot be an empty string ）,Distutils The details of the execution process will be printed , And print all the... When an exception occurs traceback, And like C When an error occurs in an external program such as a compiler , Print the entire command line .
In general , It is not possible to determine all the options when building a release , Some options may have values from the user , Or the user's system . This is the configuration file setup.cfg Purpose of existence , Users can configure options by modifying the configuration file . At build time , The processing order of options is setup Script 、 The configuration file , Command line . therefore , The installer can modify setup.cfg File to overwrite setup.py Options in ; You can also run setup.py Command line options for , To cover setup.cfg.
The basic syntax of the configuration file is as follows ：
[command]
option=value
... command Namely Distutils The order of （ such as build_py,install etc. ）,option The options supported by the command . Empty line in configuration file 、 notes （ With ’#’ start , Until the end of the line ） Will be ignored . Can pass --help Options options supported by a command , such as ：
> python setup.py --help build_ext
[...]
Options for 'build_ext' command:
--build-lib (-b) directory for compiled extension modules
--build-temp (-t) directory for temporary files (build by-products)
--inplace (-i) ignore build-lib and put compiled extensions into the
source directory alongside your pure Python modules
--include-dirs (-I) list of directories to search for header files
--define (-D) C preprocessor macros to define
--undef (-U) C preprocessor macros to undefine
--swig-opts list of SWIG command line options
[...]
Be careful , Options on the command line ”--foo-bar”, In the configuration file, write ”foo_bar”. such as , Run the following command ：
python setup.py build_ext --inplace If you don't want to enter... Every time you execute a command ”--inplace” Options , You can specify in the configuration file ：
[build_ext]
inplace=1 Other examples and considerations , You can refer to https://docs.python.org/2/distutils/configfile.html
As mentioned before , Use sdist The command can create the source code of the package and publish it , This command eventually generates a archive file .Unix The default file format on is .tar.gz, stay Windows On is ZIP file . have access to ”--formats” Option specifies the generated format , such as ：python setup.py sdist --formats=gztar,zip, After executing the command , Two files will be generated foo-1.0.tar.gz and foo-1.0.zip.
The supported formats are ：
Format
Description
zip
zip file (.zip)
gztar
gzip’ed tar file (.tar.gz)
bztar
bzip2’ed tar file (.tar.bz2)
ztar
compressed tar file (.tar.Z)
tar
tar file (.tar)
When in Unix Upper use tar When the format （gztar,bztar,ztar or tar）, Can pass owner and group Option to specify users and groups . such as ：
python setup.py sdist --owner=root --group=root If there is no clear list of documents to be released , be sdist The command contains the following files by default in the source code release ：
If you need to publish additional files , A typical approach is to write a program called MANIFEST.in Of manifest Templates .manifest The template contains how to create MANIFEST A series of instructions for a document ,sdist The command parses the template , According to the instructions in the template , And the files found are generated MANIFEST. file MANIFEST It clearly lists all the files included in the source code release . For example, here is a MANIFEST The content of the document ：
# file GENERATED by distutils, do NOT edit
setup.py
lib/__init__.py
lib/foo.py
lib/bar/__init__.py
lib/bar/bar.py
sdist The execution steps of the command are as follows ：
if the manifest file (MANIFEST by default) exists and the first line does not have a comment indicating it is generated from MANIFEST.in, then it is used as is, unaltered;
if the manifest file doesn’t exist or has been previously automatically generated, read MANIFEST.in and create the manifest;
if neither MANIFEST nor MANIFEST.in exist, create a manifest with just the default file set;
use the list of files now in MANIFEST (either just generated or read in) to create the source distribution archive(s).
If only （ again ） establish MANIFEST file , You can use the following command ：
python setup.py sdist --manifest-only If there is MANIFEST.in file , be sdist The command will generate... Based on this file MANIFEST. stay MANIFEST.in In file , One command at a time , Each command specifies the files to be included or excluded in the source code release , Take the following example ：
include *.txt
recursive-include examples *.txt *.py
prune examples/sample?/build It's easy to see , The above command means ： All inclusive .txt file ; contain examples All under directory .txt perhaps .py file ; Exclude all matches examples/sample?/build The catalog of . All these processes , All are executed after the standard rules are executed , So you can exclude files in the standard set from the template file . About MANIFEST Other contents of the document , Refer to the https://docs.python.org/2/distutils/sourcedist.html
The so-called build release （built distribution）, That is, binary packages , Or installation files . Of course, it may not really be binary , It may include Python Source code and bytecode . Build releases are created for the convenience of installers , For example, based on RPM Of Linux Users , It can be binary RPM package , And for Windows Users , It can be an executable installation file, etc . Create build releases for packages , It was introduced earlier packager The main responsibility of . They get the source code of the package and release it , Use setup Scripts and bdist Command to generate build releases . such as , Run the following command in the source tree of the package ：
python setup.py bdist Distutils Will create a release , perform “ false ” install （ stay build Directory ）, And create a build release in the default format under the current platform . Build is published in Unix The default format in is a ”dumb” Of tar file （ So it's called ”dumb”, It's because of tar Files can only work if they are unzipped to a specific directory ）, And in the Windows Is a simple executable installation file . therefore , stay Unix After running the above command on , Will be in dist Generate... In directory foo-1.0.linux-i686.tar.gz file , Unzip the file in the appropriate location , It's installed foo modular , It is equivalent to downloading the source code of the module and running it after it is released python setup.py install command . The so-called right place , Or the root directory of the file system , Or Python Of prefix Catalog , It depends. bdist_dump Command options for .bdist The order has a --formats Options , Be similar to sdist command , This option can be used to specify the format of the generated build publication , For example, command ：
python setup.py bdist --format=zip stay Unix Run this command on , Will be created foo-1.0.linux-i686.zip file , Unzip the file in the root directory to install foo modular . The format of build release support is as follows ：
gztar
gzipped tar file (.tar.gz)
ztar
compressed tar file (.tar.Z)
tar
tar file (.tar)
zip
zip file (.zip)
rpm
RPM
pkgtool
Solaris pkgtool
sdux
HP-UX swinstall
wininst
self-extracting ZIP file for Windows
msi
Microsoft Installer.
Of course , You can also not use --formats Options , It's about using bdist Subcommand for , Directly create the corresponding format . For example, use bdist_dump Command can generate all dumb archive Format （tar,ztar,gztar and zip）,bdist_rpm Will generate source code and binary RPM package ,bdist The following table lists the subcommands of ：
Command
Formats
bdist_dumb
tar, ztar, gztar, zip
bdist_rpm
rpm, srpm
bdist_wininst
wininst
bdist_msi
msi
Specific subcommand information , You can refer to 5. Creating Built Distributions — Python 2.7.18 documentation
7.1 pure Python Release （ modular ）
If only a few modules are released , These modules are not in the package , But the use of py_modules Options . For example, the source tree is as follows ：
setup.py
foo.py
bar.py
setup The script is as follows ：
from distutils.core import setup
setup(name='foobar',
version='1.0',
py_modules=['foo', 'bar'],
) After installation , The following files will be generated ：
\usr\lib\python2.7\site-packages\foobar-1.0-py2.7.egg-info
\usr\lib\python2.7\site-packages\ foo.py
\usr\lib\python2.7\site-packages\ foo.pyc
\usr\lib\python2.7\site-packages\ bar.py
\usr\lib\python2.7\site-packages\ bar.pyc
If there are many modules to be released , You can put these modules in a unified package , And then in setup The script indicates the package to be published , Instead of listing all the modules . Even if the module is not in the package , It can also be done by going to setup Script declaration root Package method to publish , Different from the actual package , The root directory may not contain __init__.py file . Take the example above , The source tree remains unchanged ,setup Scripts can also be written like this ：
from distutils.core import setup
setup(name='foobar',
version='1.0',
packages=[''],
) An empty string means root package . After installation , The generated file is the same as above . If you put the source file in a subdirectory under the root directory of the publication , For example, the source tree ：
setup.py
src/
foo.py
bar.py
This situation can still be declared root Package , Just use package_dir Option to indicate the relationship between packages and directories ：
from distutils.core import setup
setup(name='foobar',
version='1.0',
package_dir={'': 'src'},
packages=[''],
) The files generated after installation are the same as before . A more common approach is to organize multiple modules in the same package , Like in the bag foobar Contained in the foo and bar modular , The source tree is as follows ：
setup.py
foobar/
__init__.py
foo.py
bar.py
setup The script is as follows ：
from distutils.core import setup
setup(name='foobar',
version='1.0',
packages=['foobar'],
) After installation , The following files will be generated ：
\usr\lib\python2.7\site-packages\foobar-1.0-py2.7.egg-info
\usr\lib\python2.7\site-packages\foobar\ __init__.py
\usr\lib\python2.7\site-packages\foobar\ __init__.pyc
\usr\lib\python2.7\site-packages\foobar\foo.py
\usr\lib\python2.7\site-packages\foobar\foo.pyc
\usr\lib\python2.7\site-packages\foobar\bar.py
\usr\lib\python2.7\site-packages\foobar\bar.pyc
If you do not want to define the package name by the subdirectory name where the module is located , You can use package_dir Options , For example, the source tree is as follows ：
setup.py
src/
__init__.py
foo.py
bar.py
The corresponding setup The script is as follows ：
from distutils.core import setup
setup(name='foobar',
version='1.0',
package_dir={'foobar': 'src'},
packages=['foobar'],
) The file generated after installation is the same as the above example . perhaps , Directly put all modules in the root directory of the release ：
setup.py
__init__.py
foo.py
bar.py
setup The script is as follows ：
from distutils.core import setup
setup(name='foobar',
version='1.0',
package_dir={'foobar': ''},
packages=['foobar'],
) The file generated after installation is the same as the above example . If sub packages are involved , Must be in packages The options clearly indicate . however ,package_dir The values in the are automatically extended to their subdirectories . For example, the source tree is as follows ：
setup.py
src/
__init__.py
foo.py
bar.py
subfoo/
__init__.py
blah.py
setup The script is as follows ：
from distutils.core import setup
setup(name='foobar',
version='1.0',
package_dir = {'foobar':'src'},
packages=['foobar', 'foobar.subfoo'],
) After installation , The generated file is as follows ：
\usr\lib\python2.7\site-packages\foobar-1.0-py2.7.egg-info
\usr\lib\python2.7\site-packages\foobar\ __init__.py
\usr\lib\python2.7\site-packages\foobar\ __init__.pyc
\usr\lib\python2.7\site-packages\foobar\foo.py
\usr\lib\python2.7\site-packages\foobar\foo.pyc
\usr\lib\python2.7\site-packages\foobar\bar.py
\usr\lib\python2.7\site-packages\foobar\bar.pyc
\usr\lib\python2.7\site-packages\foobar\subfoo\__init__.py
\usr\lib\python2.7\site-packages\foobar\subfoo\__init__.pyc
\usr\lib\python2.7\site-packages\foobar\subfoo\blah.py
\usr\lib\python2.7\site-packages\foobar\subfoo\blah.pyc
The expansion module consists of options ext_modules Appoint .package_dir Option has no effect on the source file of the extension module , It only affects pure Python modular . For example, the source tree is as follows ：
setup.py
foo.c
If setup The script is as follows ：
from distutils.core import setup
from distutils.extension import Extension
setup(name='foobar',
version='1.0',
ext_modules=[Extension('foo', ['foo.c'])],
) The generated file is ：
\usr\lib\python2.7\site-packages\foobar-1.0-py2.7.egg-info
\usr\lib\python2.7\site-packages\ foo.so
If the source tree does not change ,setup The script is as follows ：
from distutils.core import setup
from distutils.extension import Extension
setup(name='foobar',
version='1.0',
ext_modules=[Extension('foopkg.foo', ['foo.c'])],
) The generated file is ：
\usr\lib\python2.7\site-packages\foobar-1.0-py2.7.egg-info
\usr\lib\python2.7\site-packages\foopkg\ foo.so
function install command , It will run first build command , Then run the subcommand install_lib,install_data and install_scripts.
