2024年最新以正确的方式开源 Python 项目_pypi setup里的version ，面试高分视频

最后

Python崛起并且风靡，因为优点多、应用领域广、被大牛们认可。学习 Python 门槛很低，但它的晋级路线很多，通过它你能进入机器学习、数据挖掘、大数据，CS等更加高级的领域。Python可以做网络应用，可以做科学计算，数据分析，可以做网络爬虫，可以做机器学习、自然语言处理、可以写游戏、可以做桌面应用…Python可以做的很多，你需要学好基础，再选择明确的方向。这里给大家分享一份全套的 Python 学习资料，给那些想学习 Python 的小伙伴们一点帮助！

👉Python所有方向的学习路线👈

Python所有方向的技术点做的整理，形成各个领域的知识点汇总，它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。

👉Python必备开发工具👈

工欲善其事必先利其器。学习Python常用的开发软件都在这里了，给大家节省了很多时间。

👉Python全套学习视频👈

我们在看视频学习的时候，不能光动眼动脑不动手，比较科学的学习方法是在理解之后运用它们，这时候练手项目就很适合了。

👉实战案例👈

学python就与学数学一样，是不能只看书不做题的，直接看步骤和答案会让人误以为自己全都掌握了，但是碰到生题的时候还是会一筹莫展。

因此在学习python的过程中一定要记得多动手写代码，教程只需要看一两遍即可。

👉大厂面试真题👈

我们学习Python必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有阿里大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

一个release分支是当你准备好进行产品发布的时候从develop分支创建出来的。使用以下的命令来创建：

$ git flow release start

注意，这是发布版本号第一次创建。所有完成的，准备好发布的分支必须已经合并到develop分支上。在release分支创建后，发布你的代码。任何小的bug修改需要提交到 release/ 分支上。当所有的bug被修复之后，运行以下的命令：

$ git flow release finish

这个命令会把你的release/ 分支合并到master和develop分支，这意味着你永远不需要担心这几个分支会缺少一些必要的产品变更（可能是因为一个快速的bug修复导致的）。

Hotfix

然而hotfix分支可能会很有用，在现实世界中很少使用，至少我是这样认为的。hotfix就像master分支下创建的feature分支： 如果你已经关闭了release分支，但是之后又认识到还有一些很重要的东西需要一起发布，那么就在master分支（由$git flow release finish 创建的标签）下创建一个hotfix分支，就像这样：

$ git flow hotfix start

当你完成改变和增加你的版本号使之独一无二(bump your version number)，然后完成hotfix分支：

$ git flow hotfix finish

这好像一个release分支（因为它本质上就是一种release分支），会在master和develop分支上提交修改。

我猜想它们很少使用的原因是因为已经存在一种可以给已发布的代码做出修改的机制：提交到一个未完成的release分支。当然，可能一开始，团队使用git flow release finish … 太早了，然后第二天又发现需要快速修改。随着时间的推移，他们就会为一个release 分支多留一些时间，所以，不会再需要hotfix分支。另一种需要hotfix分支情况就是如果你立即需要在产品中加入新的特性，等不及在develop分支中加入改变。不过（期望）这些都是小概率事件。

virtualenv和virtualenvwrapper

lan Bicking的virtualenv工具事实上已经成为了隔离Python环境的标准途径了。它的目标很简单：如果你的一台机子中有很多Python项目，每个都有不同的依赖（可能相同的包，但是依赖不同的版本），仅仅在一个Python安装环境中管理这些依赖几乎是不可能的。

virtualenv创建了一个“虚拟的”Python安装环境，每个环境都是相互隔离的，都有自己的site-packages, distribute和 使用pip安装包到虚拟环境而不是系统Python安装环境。 而且在你的虚拟环境中来回切换只是一个命令的事。

Doug Hellmann的virtualenvwrapper使创建和管理多个虚拟环境更容易的隔离工具。让我们继续前进，马上安装这两个工具：

如你所见，后者依赖于前者，所以简单的安装virtualenvwrapper就足够了。注意，如果你使用的是Python3，PEP-405通过venv包和pyvenv命令提供了Python原生虚拟环境的支持，在python3.3中已实现。你应该使用这个而不是前面提到的工具。

一旦你安装了virtualenvwrapper，你需要添加一行内容到你的.zhsrc文件(对bash用户来说是.bashrc文件)：

$ echo “source /usr/local/bin/virtualenvwrapper.sh” >> ~/.zshrc

这样在你的shell中增加了一些有用的命令（记得第一次使用时source一下你的.zshrc文件以使它生效）。虽然你可以使用mkvirtualenv命令直接创建一个virtualenv，但使用mkproject [OPTIONS] DEST_DIR创建一个“项目”将更有用。因为我们已经有一个现有的项目了，所有我们只需为我们的项目创建一个新的virtualenv，下附命令可以达到这效果：

你会注意到你的shell提示符在你的virtualenv之后（我的是“ossproject”，你可以使用任何你喜欢的名字）。现在任何通过pip安装的模块将安装到你的virtualenv下的site-packages。

要停止在你的项目上工作并切换回系统使用deactivate命令。你会看到命令提示符前你的virtualenv名字消失了。要重新回到你的项目上工作的话运行workon ，你会回到你的virtualenv。

除了简单地为你的项目创建virtualenv，你还会用它做其他事：生成你的requirements.txt文件，使用requirements.txt文件和-r标识可安装所有项目的依赖项。要创建该文件，在你的virtualenv运行以下命令（一旦你代码和virtualenv一起工作，就是那里）：

(ossproject)$ pip freeze > requirements.txt

你会得到一个所有你项目需要模块的列表，它以后可以被setup.py文件使用列出你的依赖关系。这里有一点需要注意：我经常在requirements.txt中将“==”改为“>=“，这样代表“我正使用包的任何的后来版本”。你是否应该或需要在项目这样做取决于实际情况，但我应该指出来。

将requirements.txt提交到你的git代码库中。此外，你现在可以添加这里的列出的包列表作为install_requirement参数的值到setup.py文件中的distutils.setup。这样做我们可以确保当上传包到PyPI后，它可以被pip安装并自动解决依赖关系。

使用py.test测试

在Python的自动测试系统里有两个主要的Python标准单元测试包（很有用）的替代品：nose和py.test。两个方案都将单元测试拓展的易于使用且增加额外的功能。说真的，哪个都是很好的选择。我更喜欢py.test因为下述几个原因：

• 支持setuptools/distutils项目
• Python的setup.py测试技能始终其作用
• 支持常见的断言（assert）语法 (而不是需要记住所有jUnit风格的断言函数)
• 更少的样板
• 支持多种测试风格
• 单元测试
• 文档测试
• nose测试

注意

如果你已经有了一个自动测试的解决方案那继续使用它吧，跳过这一节。但请记住以后的章节你将被认为在使用py.test测试，这可能会影响到配置值。

测试安装

在测试目录里，无论你如何决定都要有这个目录，创建一个名为test_<project_name>.py的文件。py.test的测试发现机制将把所有test_前缀的文件当做测试文件处理（除非明确告知）。

在这个文件里放什么很大程度上取决于你。写测试是一个很大的话题，超出这篇文章的范围。最重要的，测试对你的和潜在的捐助者都是有用的。应该标识清楚每个用例是测试的什么函数。用例应该以相同的“风格”书写，这样潜在的贡献者不必猜测在你的项目中他/她应该使用三种测试风格中的哪种。

覆盖测试

自动化测试的覆盖率是一个有争议的话题。一些人认为它给出了错误的保证是一个毫无意义的度量，其他人认为它很有用。在我看在，我建议如果你已经使用自动化测试但从来没有检查过你的测试覆盖率，现在做这样一个练习。

使用py.test，我们可以使用Ned Batchelder的覆盖测试工具。使用pip安装pytest-cov。如果你之前这样运行你的测试：

$ py.test

你可以通过传递一些新的标识生成覆盖率报告，下面是运行sandman的一个例子：

当然不是所有项目都有100%的测试覆盖率（事实上，正如你读到的，sandman没有100%覆盖），但获得100%的覆盖率是一个有用的练习。它能够揭示我之前没有留意的缺陷与重构机会。

因为，作为测试本身，自动生成的测试覆盖报可以作为你持续集成的一部分。如果你选择这样做，部署一个标记来显示当前的测试覆盖率会为你的项目增加透明度（大多数时候会极大的鼓励他人贡献）。

使用Tox进行标准化测试

一个所有Python项目维护者都需要面对的问题是兼容性。如果你的目标是同时支持Python 2.x和Python 3.x（如果你目前只支持Python 2.x，应该这样做），实际中你如何确保你的项目支持你所说的所有版本呢？毕竟，当你运行测试时，你只使用特定的版本环境来运行测试，它很可能在Python2.7.5中运行良好但在Python 2.6和3.3出现问题。

幸运的是有一个工具致力于解决这个问题。tox提供了“Python的标准化测试”，它不仅仅是在多个版本环境中运行你的测试。它创造了一个完整的沙箱环境，在这个环境中你的包和需求被安装和测试。如果你做了更改在测试时没有异常，但意外地影响了安装，使用Tox你会发现这类问题。

通过一个.ini文件配置tox：tox.ini。它是一个很容易配置的文件，下面是从tox文档中摘出来的一个最小化配置的tox.ini：

通过设置envlist为py26和py27，tox知道需要在这两种版本环境下运行测试。tox大约支持十几个“默认”的环境沙箱，包括jython和pypy。tox这个强大的工具使用不同的版本进行测试，在不支持多版本时可配置警示。

deps是你的包依赖列表。你甚至可以让tox从PyPI地址安装所有或一些你依赖包。显然，相当多的想法和工作已融入了项目。

实际在你的所有环境下运行测试现在只需要四个按键：

$ tox

一个更复杂的设置

我的书——“写地道的Python”，实际上写的是一系列的Python模块和代码。这样做是为了确保所有的示例代码按预期工作。作为我的构建过程的一部分，我运行tox来确保任何新的语法代码能正常运行。我偶尔也看看我的测试覆盖率，以确保没有语法在测试中被无意跳过。因此，我的tox.ini比上面的复杂一些，一起来看一看：

这个配置文件依旧比较简单。而结果呢？

我从输出列表里截取了一部分）。如果想看我的测试对一个环境的覆盖率，只需运行：

结果很可怕啊。

setuptools整合

tox可以和setuptools整合，这样python的setup.py测试可以运行你的tox测试。将下面的代码段放到你的setup.py文件里，这段代码是直接从tox的文档里拿来的：

现在Python的setup.py测试将下载tox并运行它。真的很酷并且很节省时间。

Sphinx文档生成器

Sphinx是由pocoo团队开发的工具[@Lesus 注：pocoo团队开发了很多优秀的产品：如Flask, Jinja2等等]。它已经用来生成Python官方文档和大多数流行的Python包的文档。它以更容易的方式从Python代码中自动产生Python文档。

使用它完成工作

Sphinx不用了解Python程序以及怎样从它们中提取出来。它只能翻译reStructuredText文件，也就意味着你的代码文档的reStructuredText译文需要让Sphinx知道才能工作，但是管理维护所有的.py文件[至少是函数和类的部分]的reStructuredText译文显然是不可行的。

幸运的是，Sphinx有一个类似javadoc的扩展，叫做autodoc,可以用来从你的代码文档中萃取出reStructuredText。为了能够充分利用Sphinx和autodoc的能力，你需要已一种特别的方式格式化你的文档。特别是，你需要使用Sphinx的Python指令时。这里就是使用reStructuredText指令来为一个函数生成文档，使输出结果的HTML文档更漂亮：

文档需要花费一点功夫，但是为了你的使用者，这个付出是值得的。好吧，好的文档使一个可用的项目去其糟粕。

Sphinx的autodoc扩展让我们可以使用很多指令，而这些指令可以自动的从你文档中生成文档。

安装

确认将Sphinx安装在你的virtualenv内，因为文档在项目里也是按版本来的。Sphinx不同的版本可能会产生不同的HTML输出。通过将其安装在你的virtualenv内，你可以以受控的方式升级你的文档。

我们要保持我们的文档在docs文件夹，将文档生成到docs/generated文件夹。在项目的根目录运行以下命令将根据你的文档字符自动重构文本文档：

$ sphinx-apidoc -F -o docs

这将产生一个包含多个文档文件的docs文件夹。此外，它创建了一个叫conf.py的文件，它将负责你的文档配置。你还会发现一个Makefile，方便使用一个命令（生成html）构建HTML文档。

在你最终生成文档之前，确保你已经在本地安装了相应的包（尽管可以使用pip，但python setup.py develop是最简单的保持更新的方法），否则sphinx-apidoc无法找到你的包。

配置:conf.py

conf.py文件创建用来控制产生的文档的各个方面。它自己会很好生成文档，所以我只简单地触及两点。

版本和发布

首先，确保你的版本和发布版本号保持最新。这些数字会作为生成的文档的一部分显示，所以你不希望它们远离了实际值。

保持你的版本最新的最简单方式就是在你的文档和setup.py文件中都从你的包的__version__属性读取。我从Flask的conf.py借用过来配置sandman的conf.py：

这就是说，为了让文档产生正确的版本号，你只需在你的项目的虚拟环境中简单的需要运行$python setup.py develop即可。现在你只需担心保持__version__为最新，因为setup.py会使用它。

html_theme

考虑到更改default到html_theme，我更喜欢原生态的东西，显然这是一个个人喜好的问题。我之所以提出这个问题是因为Python官方文档在Python 2和Python 3将默认主题更改为Pydoc主题（后者的主题是一个自定义主题仅在CPython源代码中可用）。对一些人来说，默认的主题使一个项目看起来“老”一些。

PyPI

PyPI，Python包索引（以前被称为“Cheeseshop”）是一个公开可用的Python包中央数据库。PyPI是你的项目发布的地方。一旦你的包（及其相关的元数据）上传到PyPI，别人通过pip或easy_instal可以下载并安装它。这一点得强调一下：即使你的项目托管在GitHub，直到被上传到PyPI后你的项目才是有用的。当然，有些人可以复制你的git库任何直接手工安装它，但更多的人想使用pip来安装它。

最后的一步

如果你已经完成了所有的前面部分中的步骤，你可能急着想把你的包上传到PyPI，供其他人使用！

先别急着做上述事情，在分发你的包之前，有一个叫做cheesecake的有用的工具有助于运行最后一步。它分析你的包并指定一个分类的数字分数。它衡量你的包在打包、安装、代码质量以及文档的数量和质量方面是否容易/正确。

除了作粗略衡量的“准备”，cheesecake在完整性检查方面很优秀。你会很快看到你的setup.py文件是否有错或者有没有忘记为一个文件制作文档。我建议在上传每个项目到PyPI之前运行一下它，而不仅只是第一个。

初始化上传

现在，你已经确定了你的代码不是垃圾和当人们安装它时不会崩溃，让我们把你的包放到PyPI上吧！你将会通过setuptools和setup.py脚本交互。如果这是第一次上传到PyPI，你将首先注册它：

$ python setup.py register

注意：如果你还没有一个免费的PyPI账户，你将需要现在去注册一个，才能注册这个包[@Lesus 注：注册之后还需要到邮箱去验证才行]。在你已使用了上面注册之后，你就可以创建发布包和上传到PyPI了:

$ python setup.py sdist upload

上面这个命令建立一个源码发布版(sdist)，然后上传到PyPI.如果你的包不是纯粹的Python（也就是说，你有二进制需要编译进去），你就需要发布一个二进制版，请看setuptools文档，了解更多。

发布及版本号

PyPI使用发行版本模型来确定你软件包的哪个版本是默认可用的。初次上传后，为使你软件包的每次更新后在PyPI可用，你需要指定一个新版本号创建一个发布。版本号管理是一个相当复杂的课题，PEP有专门的内容：PEP 440——版本识别和依赖指定。我建议参照PEP 400指南（明显地），但如果你选择使用不同版本的方案，在setup.py中使用的版本比目前PyPI中的版本“高”，这样PyPI才会认为这是一个新版本。

工作流

将你的第一个发布版本上传到PyPI后，基本的工作流程如下：

继续在你的项目上工作 (比如修复bug，添加新特性等等)

确保测试通过

在git-flow中创建一个发布分支“冻结”你的代码

在你项目的__init__.py文件里更新__version__number版本变量

多次测试运行setup.py，将新版本上传到PyPI

使用TravisCI持续集成

持续集成是指一个项目中所有变化不断整合的过程（不是周期性的批量更新）。就我们而言，这意味每次我们GitHub提交时，我们通过测试运行来发现是否有什么异常，正如你想象的，这是一个非常有价值的实践。不要有“忘记运行测试”的提交。如果你的提交通不过测试，你将收到一封电子邮件被告知。

TravisCI是一种使GitHub项目持续集成更容易的服务。如果你还没有账号到这看一下注册一个，完成这些之后，在我们进入CI之前我们先需要创建一个简单的文件。

通过.travis.yml配置

在TravisCI上的不同项目通过一个.travis.yml文件来配置，这个文件在项目的根目录。简要地说，我们需要告诉Travis：

1. 我们项目使用的语言是什么
2. 它使用的是语言的哪个版本
3. 使用什么命令安装它
4. 使用什么命令运行项目的测试

这些都是很直接的东西。下面是sandman.travis.yml的内容：

在列出语言和版本后，我们告诉Travis如何安装我们的包。在install这行，确认包含下面这行：

• “pip install -r requirements.txt --use-mirrors”

这是pip安装我们项目的要求（如果有必要的话使用PyPI镜像站点）。另外的两行内容是sandman特有的。它使用一个额外的服务（coveralls.io）来连续监测测试用例的覆盖率，这不是所有项目都需要的。

：列出能运行该项目测试的命令。与上面一样，sandman还需要做一些额外的工作。你的项目需要的只有Python的setup.py测试，after_success部分也可以一块删掉。

一旦你提交了这个文件并在TravisCI中激活了你的项目的，push到GitHub。一会儿后，你会看到一个基于你最近提交的编译结束结果。如果成功了，你的编译呈现“绿色”和并且状态页会显示编译通过。你可以看到你项目在任何时间的编译历史。这对对人开发特别有用，在历史页可以看到特定开发者出错和编译的频率…

你还会收到一封通知你编译成功的电子邮件。当然你也可以设置只有在出错或错误被修复时才有邮件通知，但编译输出结果相同时也不会发送。这是非常有用的，你在不必被无用的“编译通过！”邮件淹没的同时在发生改变仍会收到警示。

用ReadTheDocs做持续文档集成

尽管PyPI有一个官方文档站点（pythonhosted.org），但是ReadTheDocs提供了一个更好的体验。为什么？ReadTheDocs有针对GitHub非常棒的集成。当你注册ReadTheDocs的时候，你就会看到你的所有GitHub 代码库。选择合适的代码库，做一些小幅的配置，那么你的文档就会在你每次提交到GitHub之后自动重新生成。

学好 Python 不论是就业还是做副业赚钱都不错，但要学会 Python 还是要有一个学习规划。最后大家分享一份全套的 Python 学习资料，给那些想学习 Python 的小伙伴们一点帮助！

一、Python所有方向的学习路线

Python所有方向路线就是把Python常用的技术点做整理，形成各个领域的知识点汇总，它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。

二、学习软件

工欲善其事必先利其器。学习Python常用的开发软件都在这里了，给大家节省了很多时间。

三、全套PDF电子书

书籍的好处就在于权威和体系健全，刚开始学习的时候你可以只看视频或者听某个人讲课，但等你学完之后，你觉得你掌握了，这时候建议还是得去看一下书籍，看权威技术书籍也是每个程序员必经之路。

四、入门学习视频

我们在看视频学习的时候，不能光动眼动脑不动手，比较科学的学习方法是在理解之后运用它们，这时候练手项目就很适合了。

五、实战案例

光学理论是没用的，要学会跟着一起敲，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。

六、面试资料

我们学习Python必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有阿里大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

面试资料

我们学习Python必然是为了找到高薪的工作，下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料，并且有阿里大佬给出了权威的解答，刷完这一套面试资料相信大家都能找到满意的工作。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！