setup的用法
安装python的包,从源上安装的话,直接pip install xxx
,但是如果需要从本地安装,那么就需要python setup.py install
,但是一般建议用的是pip install -e .
,这样pip可以帮助安装依赖项,以及卸载维护,用setup会很麻烦,需要手动删除。注意:__init__.py是要想让一个文件夹成为包的必须的文件,这个文件可以为空,但是必须得有。setup.py是用来安装模块。
1.示例
from setuptools import setup, find_packages
setup(
name = "test",
version = "1.0",
keywords = ("test", "xxx"),
description = "eds sdk",
long_description = "eds sdk for python",
license = "MIT Licence",
url = "http://test.com",
author = "test",
author_email = "test@gmail.com",
packages = find_packages(),
include_package_data = True,
platforms = "any",
install_requires = [],
scripts = [],
entry_points = {
'console_scripts': [
'test = test.help:main'
]
}
# 此项需要,否则卸载时报windows error
zip_safe=False
)
2.setup.py各参数
--name 包名称
--version (-V) 包版本
--author 程序的作者
--author_email 程序的作者的邮箱地址
--maintainer 维护者
--maintainer_email 维护者的邮箱地址
--url 程序的官网地址
--license 程序的授权信息
--description 程序的简单描述
--long_description 程序的详细描述
--platforms 程序适用的软件平台列表
--classifiers 程序的所属分类列表
--keywords 程序的关键字列表
--packages 需要处理的包目录(包含__init__.py的文件夹)
--py_modules 需要打包的python文件列表
--download_url 程序的下载地址
--cmdclass
--data_files 打包时需要打包的数据文件,如图片,配置文件等
--scripts 安装时需要执行的脚步列表
--package_dir 告诉setuptools哪些目录下的文件被映射到哪个源码包。一个例子:package_dir = {'': 'lib'},表示“root package”中的模块都在lib目录中。
--requires 定义依赖哪些模块
--provides定义可以为哪些模块提供依赖
--find_packages() 对于简单工程来说,手动增加packages参数很容易,刚刚我们用到了这个函数,它默认在和setup.py同一目录下搜索各个含有 __init__.py的包。其实我们可以将包统一放在一个src目录中,另外,这个包内可能还有aaa.txt文件和data数据文件夹。另外,也可以排除一些特定的包find_packages(exclude=["*.tests", "*.tests.*", "tests.*", "tests"])
--install_requires = ["requests"] 需要安装的依赖包
--entry_points 动态发现服务和插件
2.1 install_requires
在install_requires流行以前,往往会使用requrements.txt来声明依赖。 对install_requires
来说,只是把上述形式换成字符串列表而已。比如:
setup(
...
install_requires=[
'argparse',
'setuptools==38.2.4',
'docutils >= 0.3',
'Django >= 1.11, != 1.11.1, <= 2',
'requests[security, socks] >= 2.18.4',
],
)
以上展示了五种常用形式:
'argparse'
,只包含包名。 这种形式只检查包的存在性,不检查版本。 方便,但不利于控制风险。'setuptools==38.2.4'
,指定版本。 这种形式把风险降到了最低,确保了开发、测试与部署的版本一致,不会出现意外。 缺点是不利于更新,每次更新都需要改动代码。'docutils >= 0.3'
,这是比较常用的形式。 当对某个库比较信任时,这种形式可以自动保持版本为最新。'Django >= 1.11, != 1.11.1, <= 2'
,这是比较复杂的形式。 如这个例子,保证了Django的大版本在1.11和2之间,也即1.11.x;并且,排除了已知有问题的版本1.11.1(仅举例)。 对于一些大型、复杂的库,这种形式是最合适的。'requests[security, socks] >= 2.18.4'
,这是包含了额外的可选依赖的形式。 正常安装requests会自动安装它的install_requires
中指定的依赖,而不会安装security
和socks
这两组依赖。 这两组依赖是定义在它的extras_require
中。 这种形式,用在深度使用某些库时。
指定包名是必须的,而版本控制与可选依赖,则是高级形式。 这不仅仅是install_requires
的形式,而是对setup.py的所有require都适用。
如果其中某些依赖,在官方的PyPI中不存在,而是发布在某些私有源中,则需要指定dependency_links
。
setup(
...
dependency_links=[
'https://pypi.python.org/simple',
'http://my.company.com/pypi/',
...
],
)
2.2 extras_require
extras_require
指定了可选的功能与依赖。 某些特殊的、偏门的功能,可能绝大多数用户不会去使用。 这些功能的依赖,不适合放在install_requires
里。 这时就可以用extras_require
来指定。
setup(
...
extras_require={
'security': ['pyOpenSSL>=0.14', 'cryptography>=1.3.4', 'idna>=2.0.0'],
'socks': ['PySocks>=1.5.6, !=1.5.7'],
},
)
以上以requests的设置为例。 extras_require
需要一个dict,其中按(自定义的)功能名称进行分组,每组一个列表,与install_requires
规则相同。
使用时,可以用类似'requests[security, socks]'
的形式来指定。
2.3 python_requires
python_requires
指定运行时需要的Python版本。
现在还在使用Python 2的,基本上都是用Python 2.7.x版本。 它仅做维护性修改,基本上没有代码的兼容性问题。 而使用Python 3的,则每一个小版本都有变化,代码可能出现不兼容问题。 指定python_requires
可以避免这类问题,在安装时就会报错、提示。
比如下例,指定该库仅在Python 2.7.x版本使用。
setup(
...
python_requires='>=2.7, <=3',
)
2.5 tests_require
tests_require
是仅仅在测试时需要使用的依赖。
有些依赖库,仅仅在测试代码中使用,在正常发布的代码中是没有用的。 比如,pytest、pytest-cov等,放在install_requires
中不合适。 这些都放在tests_require
即可,可以帮助搭建测试环境,而不影响用户的正常使用。
2.6 setup_requires
setup_requires
是只在执行setup.py时需要的依赖。 这通常是为一些setuptools插件而准备的配置,比如pytest-runner。
setup(
...
tests_require=[
'pytest>=3.3.1',
'pytest-cov>=2.5.1',
],
setup_requires=[
'pytest-runner>=3.0',
],
)
比如,进行以上配置后,在执行python setup.py test
时,可以自动安装这三个库,确保测试的正常运行。