使用setuptools构建python包

1.python包分发方式

源码包分发

源码包安装的过程，是先解压，再编译，最后才安装，所以它是跨平台的，由于每次安装都要进行编译，相对二进包安装方式来说安装速度较慢。

源码包的本质是一个压缩包，其常见的格式有：

二进制包分发

二进制包的安装过程省去了编译的过程，直接进行解压安装，所以安装速度较源码包来说更快。

由于不同平台的编译出来的包无法通用，所以在发布时，需事先编译好多个平台的包。

二进制包的常见格式有：

eggs 与 wheels的区别

Egg 格式是由 setuptools 在 2004 年引入，而 Wheel 格式是由 PEP427 在 2012 年定义。Wheel 的出现是为了替代 Egg，它的本质是一个zip包，其现在被认为是 Python 的二进制包的标准格式。

以下是 Wheel 和 Egg 的主要区别：

• Wheel 有一个官方的 PEP427 来定义，而 Egg 没有 PEP 定义
• Wheel 是一种分发格式，即打包格式。而 Egg 既是一种分发格式，也是一种运行时安装的格式，并且是可以被直接 import
• Wheel 文件不会包含 .pyc 文件
• Wheel 使用和 PEP376 兼容的 .dist-info 目录，而 Egg 使用 .egg-info 目录
• Wheel 有着更丰富的命名规则。
• Wheel 是有版本的。每个 Wheel 文件都包含 wheel 规范的版本和打包的实现
• Wheel 在内部被 sysconfig path type 管理，因此转向其他格式也更容易

wheel 包可以通过 pip 来安装，只不过需要先安装 wheel 模块，然后再使用 pip 的命令。

$ pip install wheel
$ pip wheel --wheel-dir=/local/wheels pkg

2.setuptools构建包的格式

构建源码发布包

用于发布一个 python 模块或项目，将源码打包成 tar.gz 或者 zip 压缩包

$ python setup.py sdist

使用sdist 将根据当前平台创建默认格式的存档。在类 Unix 平台上，将创建后缀后为 .tar.gz 的 gzip 压缩的tar文件分发包，而在Windows上为 zip 文件。

也可以通过指定要的发布包格式，具体如下

$ python setup.py sdist --formats=gztar,zip

创建一个压缩的tarball和一个zip文件，可用格式为：

对以上的格式，有几点需要注意一下：

• 在版本3.5中才添加了对 xztar 格式的支持
• zip 格式需要你事先已安装相应的模块，zip程序或zipfile模块

另外，可以指定归档文件的所有文件归root拥有

python setup.py sdist --owner=root --group=root

构建二进制分发包

Python模块支持打包成 exe 这样的二进制软件包，在windows中可以双击 exe 进行软安装。

$ python setup.py bdist_wininst

python模块也是支持 rpm 包的构建，在 Linux 中可以使用 rpm 来安装包。

$ python setup.py bdist_rpm

python模块支持打包成 egg 包

$ python setup.py bdist_egg

如果需要安装到多个平台，既有 Windows 也有 Linux，按照上面的方法，多种格式我们要执行多次命令，为了方便可以执行如下这条命令，即可生成多个格式的进制

$ python setup.py bdist

3.setup.py文件编写

setup.py 简单的使用示例

from setuptools import setup, find_packages


setup(
    name="mytest",
    version="1.0",
    author="xxx",
    author_email="xxx@163.com",
    description="Learn to Pack Python Module",

    # 项目主页
    url="http://xxx.com/", 

    # 你要安装的包，通过 setuptools.find_packages 找到当前目录下有哪些包
    packages=find_packages()
)

接下来，扩充这个setup函数，增加更多的参数

程序分类信息

classifiers 参数说明包的分类信息。所有支持的分类列表见：https://pypi.org/pypi?%3Aaction=list_classifiers

示例：

from setuptools import setup, find_packages

setup(
    classifiers = [
        # 发展时期,常见的如下
        #   3 - Alpha
        #   4 - Beta
        #   5 - Production/Stable
        'Development Status :: 3 - Alpha',

        # 开发的目标用户
        'Intended Audience :: Developers',

        # 属于什么类型
        'Topic :: Software Development :: Build Tools',

        # 许可证信息
        'License :: OSI Approved :: MIT License',

        # 目标 Python 版本
        'Programming Language :: Python :: 2',
        'Programming Language :: Python :: 2.7',
        'Programming Language :: Python :: 3',
        'Programming Language :: Python :: 3.3',
        'Programming Language :: Python :: 3.4',
        'Programming Language :: Python :: 3.5',
    ]
)

关于文件的分发

from setuptools import setup, find_packages


setup(
    name="mytest",
    version="1.0",
    author="xxx",
    author_email="xxx@163.com",
    description="Learn to Pack Python Module",
    url="http://xxx.com/", 
    packages=find_packages(),

    # 安装过程中，需要安装的静态文件，如配置文件、service文件、图片等
    data_files=[
        ('', ['conf/*.conf']),
        ('/usr/lib/systemd/system/', ['bin/*.service']),
               ],

    # 希望被打包的文件
    package_data={
        '':['*.txt'],
        'bandwidth_reporter':['*.txt']
               },
    # 不打包某些文件
    exclude_package_data={
        'bandwidth_reporter':['*.txt']
               }
)

除了以上的参数配置之外，还可以使用一个叫做 MANIFEST.in 的文件，来控制文件的分发。

如下这是一个 MANIFEST.in 的样例：

include *.txt
recursive-include examples *.txt *.py
prune examples/sample?/build

这些配置，规定了如下几点

• 所有根目录下的以 txt 为后缀名的文件，都会分发
• 根目录下的 examples 目录 和 txt、py文件都会分发
• 路径匹配上 examples/sample?/build 不会分发

MANIFEST.in 需要放在和 setup.py 同级的顶级目录下，setuptools 会自动读取该文件。

关于依赖包下载安装

from setuptools import setup, find_packages


setup(
    ...

    # 表明当前模块依赖哪些包，若环境中没有，则会从pypi中下载安装
    install_requires=['docutils>=0.3'],

    # setup.py 本身要依赖的包，这通常是为一些setuptools的插件准备的配置
    # 这里列出的包，不会自动安装。
    setup_requires=['pbr'],

    # 仅在测试时需要使用的依赖，在正常发布的代码中是没有用的。
    # 在执行python setup.py test时，可以自动安装这三个库，确保测试的正常运行。
    tests_require=[
        'pytest>=3.3.1',
        'pytest-cov>=2.5.1',
    ],

    # 用于安装setup_requires或tests_require里的软件包
    # 这些信息会写入egg的 metadata 信息中
    dependency_links=[
        "http://example2.com/p/foobar-1.0.tar.gz",
    ],

    # install_requires 在安装模块时会自动安装依赖包
    # 而 extras_require 不会，这里仅表示该模块会依赖这些包
    # 但是这些包通常不会使用到，只有当你深度使用模块时，才会用到，这里需要你手动安装
    extras_require={
        'PDF':  ["ReportLab>=1.2", "RXP"],
        'reST': ["docutils>=0.3"],
    }
)

关于 install_requires， 有以下五种常用的表示方法：

1. 'argparse'，只包含包名。 这种形式只检查包的存在性，不检查版本。 方便，但不利于控制风险。
2. 'setuptools==38.2.4'，指定版本。 这种形式把风险降到了最低，确保了开发、测试与部署的版本一致，不会出现意外。 缺点是不利于更新，每次更新都需要改动代码。
3. 'docutils >= 0.3'，这是比较常用的形式。 当对某个库比较信任时，这种形式可以自动保持版本为最新。
4. 'Django >= 1.11, != 1.11.1, <= 2'，这是比较复杂的形式。 如这个例子，保证了Django的大版本在1.11和2之间，也即1.11.x；并且，排除了已知有问题的版本1.11.1（仅举例）。 对于一些大型、复杂的库，这种形式是最合适的。
5. 'requests[security, socks] >= 2.18.4'，这是包含了额外的可选依赖的形式。 正常安装requests会自动安装它的install_requires中指定的依赖，而不会安装security和socks这两组依赖。 这两组依赖是定义在它的extras_require中。 这种形式，用在深度使用某些库时。

关于安装环境的限制

有些库并不是在所以的 Python 版本中都适用的，若一个库安装在一个未兼容的 Python 环境中，理论上不应该在使用时才报错，而应该在安装过程就使其失败，提示禁止安装。

这样的功能，可以使用 python_requires 来实现。

setup(
    ...
    python_requires='>=2.7, <=3',
)

生成可执行文件的分发

from setuptools import setup, find_packages


setup(
    name="mytest",
    version="1.0",
    author="xxx",
    author_email="xxx@163.com",
    description="Learn to Pack Python Module",
    url="http://xxx.com/", 
    packages=find_packages(),

    # 用来支持自动生成脚本，安装后会自动生成 /usr/bin/foo 的可执行文件
    # 该文件入口指向 foo/main.py 的main 函数
    entry_points={
        'console_scripts': [
            'foo = foo.main:main'
        ]
    },

    # 将 bin/foo.sh 和 bar.py 脚本，生成到系统 PATH中
    # 执行 python setup.py install 后
    # 会生成 如 /usr/bin/foo.sh 和 如 /usr/bin/bar.py
    scripts=['bin/foo.sh', 'bar.py']
)

上面的 scripts 里有的脚本中有 sh 和 py 后缀，那么安装后，setuptools 会原封不动的移动到 /usr/bin 中，并添加可执行权限。

指定release

setup.py 里只能指定 version，而不能指定 release，如果你需要变更版本号，可以使用 --release 参数进行指定

python setup.py bdist_rpm --release=20220107