环境

环境

为了正确地跑起来，你的应用需要依赖许多不同的软件。 就算是再怎么否认这一点的人，也无法否认至少需要依赖Flask本身。 你的应用的运行环境，在当你想要让它跑起来时，是至关重要的。 幸运的是，我们有许多工具可以减低管理环境的复杂度。

使用virtualenv来管理环境

virtualenv是一个能把你的应用隔离在一个虚拟环境中的工具。 一个虚拟环境是一个包含了你的应用依赖的软件的文件夹。一个虚拟环境同时也封存了你在开发时的环境变量。 与其把依赖包，比如Flask，下载到你的系统包管理文件夹，或用户包管理文件夹，我们可以把它下载到对应当前应用的一个隔离的文件夹之下。 这使得你可以指定一个特定的Python二进制版本，取决于当前开发的项目。

virtualenv也可以让你给不同的项目指定同样的依赖包的不同版本。 当你在一个老旧的包含众多不同项目的平台上开发时，这种灵活性十分重要。

用了virtualenv，你将只会把少数几个Python模块安装到系统的全局空间中。其中一个会是virtualenv本身：

# 使用pip安装virtualenv
$ pip install virtualenv

安装完virtualenv，就可以开始创建虚拟环境。切换到你的项目文件夹，运行virtualenv命令。这个命令接受一个参数，作为虚拟环境的名字（同样也是它的位置，在当前文件夹ls下你就知道了）。

$ virtualenv venv
New python executable in venv/bin/python
Installing setuptools, pip...done.

这将创建一个包含所有依赖的文件夹。

一旦新的virtual environment已经准备就绪，你需要给对应的virtual environment下的bin/activate脚本执行source，来激活它。

$ source venv/bin/activate

你可以通过运行which python看到：“python”现在指向的是virtual environment中的二进制版本。

$ which python
/usr/local/bin/python
$ source venv/bin/activate
(venv)$ which python
/Users/robert/Code/myapp/venv/bin/python

当一个virtual environment被激活了，依赖包会被pip安装到virtual environment中而不是全局系统环境。

你也许注意到了，你的shell提示符发生了改变。 virtualenv在它前面添加了当前被激活的virtual environment，所以你能意识到你并不存在于全局系统环境中。

运行deactivate命令，你就能离开你的virtual environment。

(venv)$ deactivate
$

使用virtualenvwrapper管理你的virtual environment

我想要让你了解到virtualenvwrapper对于前面的工作做了什么改进，这样你就知道为什么你应该使用它。

虚拟环境文件夹现在已经位于你的项目文件夹之下。 但是你仅仅是在激活了虚拟环境后才会跟它交互。它甚至不应该被放入版本控制中。所以它呆在项目文件夹中也是挺碍眼的。 解决这个问题的一个方法就是使用virtualenvwrapper。这个包把你所有的virtual environment整理到单独的文件夹下，通常是~/.virtualenvs/。

要安装virtualenvwrapper，遵循这个文档中的步骤。

注意 确保你在安装virtualenvwrapper时不在任何一个virtual environment中。你需要把它安装在全局空间，而不是一个已存在的virtual environment中

现在，你不再需要运行virtualenv来创建一个环境，只需运行mkvirtualenv：

$ mkvirtualenv rocket
New python executable in rocket/bin/python
Installing setuptools, pip...done.

在你的virtual environment目录之下，比如在~/.virtualenv之下，mkvirtualenv创建了一个文件夹，并替你激活了它。 就像普通的virtualenv，python和pip现在指向的是virtual environment而不是全局系统。 为了激活想要的环境，运行这个命令：workon [environment name]，而deactivate依然会关闭环境。

记录依赖变动

随着项目增长，你会发现它的依赖列表也一并随着增长。在你能运行一个Flask应用之前，即使已经需要数以十记的依赖包也毫不奇怪。 管理依赖的最简单的方法就是使用一个简单的文本文件。 pip可以生成一个文本文件，列出所有已经安装的包。它也可以解析这个文件，并在新的系统（或者新的环境）下安装每一个包。

pip freeze

requirements.txt是一个常常被许多Flask应用用于列出它所依赖的包的文本文件。它是通过pip freeze > requirements.txt生成的。 使用pip install -r requirements.txt，你就能安装所有的包。

注意 在freeze或install依赖包时，确保你正为于正确的virtual environment之中。

手动记录依赖变动

随着项目增长，你可能会发现pip freeze中列出的每一个包并不再是运行应用所必须的了。 也许有些包只是在开发时用得上。pip freeze没有判断力；它只是列出了当前安装的所有的包。所以你只能手动记录依赖的变动了。 你可以把运行应用所需的包和开发应用所需的包分别放入对应的require_run.txt和require_dev.txt。

版本控制

选择一个版本控制系统并使用它。 我推荐Git。如我所知，Git是当下最大众的版本控制系统。 在删除代码的时候无需担忧潜在的巨大灾难是无价的。 你现在可以对过去那种把不要的代码注释掉的行为说拜拜了，因为你可以直接删掉它们，即使将来突然需要，也可以通过git revert来恢复。 另外，你将会有整个项目的备份，存在Github,Bitbucket或你自己的Git server。

什么不应该在版本控制里

我通常不把一个文件放在版本控制里，如果它满足以下两个原因中的一个。

  1. 它是不必要的
  2. 它是不公开的。

编译的产物，比如.pyc，和virtual environment（如果你因为某些原因没有使用virtualenvwrapper）正是前者的例子。 它们不需要加入到版本控制中，因为它们可以通过.py或requirements.txt生成出来。

接口密钥（调用接口时必须传入的参数），应用密钥，以及数据库证书则是后者的例子。 它们不应该在版本控制中，因为一旦泄密，将造成严重的安全隐患。

注意 在做安全相关的决定时，我会假设稳定版本库将会在一定程度上被公开。这意味着要清除所有的隐私，并且永不假设一个安全漏洞不会被发现， 因为“谁能想到他们会干出什么事情？”

在使用Git时，你可以在版本库中创建一个特别的文件名为.gitignore。 在里面，能使用正则表达式来列出对应的文件。任何匹配的文件将被Git所忽略。 我建议你至少在其中加入*.pyc和/instance。instance文件夹中存放着跟你的应用相关的不便公开的配置。

.gitignore:
*.pyc
instance/

参见

调试

调试模式

Flask有一个便利的特性叫做“debug mode”。在你的应用配置中设置debug = True就能启动它。 当它被启动后，服务器会在代码变动之后重新加载，并且一旦发生错误，错误会打印成一个带交互式命令行的调用栈。

注意 不要在生产环境中开启debug mode。交互式命令行运行任意的代码输入，如果是在运行中的网站上，这将导致安全上的灾难性后果。

另见

Flask-DebugToolbar

Flask-DebugToolbar 是用来调试你的应用的另一个得力工具。在debug mode中，它在你的应用中添加了一个侧边条。 这个侧边条会给你提供有关SQL查询，日志，版本，模板，配置和其他有趣的信息。

总结

  • 使用virtualenv来打包你的应用的依赖包。
  • 使用virtualenvwrapper来打包你的virtual environment。
  • 使用一个或多个文本文件来记录依赖变化。
  • 使用一个版本控制系统。我推荐Git。
  • 使用.gitignore来排除不必要的或不能公开的东西混进版本控制。
  • debug mode会在开发时给你有关bug的信息。
  • Flaks-DebugToolbar拓展将给你有关bug更多的信息。