深度定制Python的Flask框架开发环境的一些技巧总结
Flask环境配置
你的应用程序可能需要大量的软件包才能正常的工作。如果都不需要Flask包的话，你有可能读错了教程。当应用程序运行的时候，你的应用程序的环境基本上是所有一切事情的根基。我们是幸运的，因为有许多方式使得我们能够轻松地管理我们的环境。
使用virtualenv管理你的环境
virtualenv是用于在所谓虚拟环境中隔离你的应用程序的一个工具。一个虚拟环境是包含了你的应用依赖的软件的一个目录。一个虚拟环境也能够改变你的环境变量以维持你的开发环境包含的环境变量。不用下载包，像Flask，到你系统级或者用户级的包目录，我们可以下载它们到一个独立的并且只为我们应用使用的目录。这就可以很容易地指定使用的Python的版本以及每一个项目依赖的包。
Virtualenv也可以让你在不同的项目中使用相同的包的不同版本。这种灵活性可能是十分重要的，如果你正使用一个旧的系统并且它的上面有几个项目需要不同的版本。
当使用virtualenv的时候，你通常只需要安装几个的Python包在你的系统上。其中一个就是virtualenv本身。你可以使用Pip来安装virtualenv包。
一旦在你的系统上安装了virtualenv，你可以开始创建虚拟环境。前往你项目所在的目录并且运行virtualenv命令。它需要一个参数，这个参数就是虚拟环境的目标目录。下面展示了它大概的样子。
$virtualenvvenv Newpythonexecutableinvenv/bin/python InstallingSetuptools...........[...].....done. InstallingPip..................[...].....done.
virtualenv创建一个新的目录，依赖包将会安装到这个目录中。
一旦新的虚拟环境已经创建，你必须激活它，通过发动创建在虚拟环境里的bin/activate脚本。
$whichpython /usr/local/bin/python $sourcevenv/bin/activate (venv)$whichpython /Users/robert/Code/myapp/venv/bin/python
bin/activate脚本对你的shell环境变量进行一些改变以致一切都指向新的虚拟环境而不是全局系统。你可以在上面的代码块中看到效果。激活后，python命令指向虚拟环境的中Python的bin目录。当虚拟环境激活后，使用Pip安装的依赖包会被下载到虚拟环境中而不是全局系统。
你可能会注意到shell中的提示符也已经改变了。virtualenv预先设定目前激活虚拟环境的名称，因此你会知道你不是在全局系统上工作。
你可以通过运行deactivate命令停用你的虚拟环境。
(venv)$deactivate
virtualenvwrapper
virtualenvwrapper是一个用于管理virtualenv创建的虚拟环境的软件包。我不想提到这个工具，直到你看到了virtualenv的基础知识以便你理解它改善了什么以及为什么我们应该使用它。
上一部分创建的虚拟环境目录会给你的项目库带来一些混乱。你只需要激活虚拟环境和它进行交互，但是它不应该出现在版本控制中，因此这个虚拟环境目录就不应该在这里。解决方案就是使用virtualenvwrapper。这个软件包会把所有你的虚拟环境放在一个目录的方式，通常默认是在~/.virtualenvs/。
要安装virtualenvwrapper，请按照文档中的说明，文档位于http://virtualenvwrapper.readthedocs.org/en/latest/install.html。
请确保在安装virtualenvwrapper之前你已经停用所有的虚拟环境。你需要把它安装在全局系统中，而不是虚拟环境中。
现在，不用运行virtualenv来创建一个环境，你需要运行mkvirtualenv：
$mkvirtualenvrocket Newpythonexecutableinrocket/bin/python Installingsetuptools...........[...].....done. Installingpip..................[...].....done. (rocket)$mkvirtualenv在你虚拟环境目录中创建一个文件夹并且为你激活虚拟环境。就像上面的virtualenv一样，python以及pip指向虚拟环境中而不是全局系统的二进制文件。要激活一个特定的环境，使用命令：workon[environmentname]。deactivate仍然会停用虚拟环境。
安装依赖包
随着项目的发展，你会发现依赖包的列表会增大。需要几十个Python包来运行一个Flask应用程序的情况并不少见。管理这些最简单的方法是用一个简单的文本文件。Pip能够生成一个列出所有已安装的包的文本文件。在一个新的系统上，或者在一个新的刚创建的环境上也能读取文件中的列表并且安装它们中每一个。
pipfreeze： requirements.txt是一个文本文件，它被许多Flask应用程序用来列出运行应用所有需要的包。这个代码块用来说明如何创建这个文件接着下一个代码块用来说明在一个新环境中如果使用这个文件来安装依赖包。
(rocket)$pipfreeze>requirements.txt $workonfresh-env (fresh-env)$pipinstall-rrequirements.txt [...] SuccessfullyinstalledflaskWerkzeugJinja2itsdangerousmarkupsafe Cleaningup... (fresh-env)$人工管理依赖包
随着项目的发展，你可能会发现pipfreeze列出的某些包实际上并不是运行应用必须的。你安装这些包仅仅为开发用的。pipfreeze并不能区分，它仅仅列出目前已经安装的包。因此，你可能要手动地管理这些依赖包。你可以分别把那些运行应用必须的包放入require\_run.txt以及那些开发应用程序需要的包放入require\_dev.txt。
版本控制
选择一个版本控制系统并且使用它。我推荐Git。从我所看到的，Git是这些天来新项目最流行的选择。能够删除代码而不必担心犯了一个不可逆转的错误是非常宝贵的。你也可以让你的项目摆脱大量注释掉的代码的困扰，因为你可以删除它们，以后如有需要可以恢复它们。另外，你可以在GitHub，Bitbucket或者你自己的Gitolite服务器上备份整个项目。
置身版本控制之外的文件
我通常会让一个文件置身版本控制之外有两个原因：要么就是它会让整个项目显得混乱，要么它就是一个很隐私的密钥/证书。编译的.pyc文件和虚拟环境—如果由于某些原因你没有使用virtualenvwrapper—就是让项目显得很混乱的例子。它们不需要在版本控制之中因为它们能够分别地从.py文件和你的requirements.txt文件重新创建。
API秘钥，应用程序秘钥以及数据库证书是很隐私的密钥/证书的示例。它们不应该出现在版本控制中因为它们的曝光将是一个巨大的安全漏洞。
当做跟安全有关的决定的时候，我总是喜欢假设我的版本库将在某个时候变成公开的。这就意味着要保守秘密并且从不假设一个安全漏洞不会被发现，“谁来猜猜他们能做到”这类型的假设被称为通过隐匿来实现安全，这是十分槽糕的策略。
当使用Git的时候，你可以在你的版本库中创建名为.gitignore的一个特殊文件。在这个文件里，使用列表通配符来匹配文件名。任何匹配其中一个模式的文件名都会被Git给忽略掉。我推荐使用.gitignore来控制不需要版本控制的文件。例如：
*.pyc instance/Instance文件夹是用于以一种更安全地方式提供给你的应用程序敏感配置变量。我将会在后面更多地谈到它。
你可以阅读更多的关于.gitignore的内容从这里：http://git-scm.com/docs/gitignore
调试
1.调试模式
Flask有一个称为调试模式方便的功能。要打开调试功能的话，你只必须在你的开发配置中设置debug=True。当它打开的时候，服务器会在代码变化的时候自动加载并且出错的时候会伴随着一个堆栈跟踪和一个交互式控制台。
小心！不要在生产环境中使用调试模式。交互式控制台允许执行任意代码并会是一个巨大的安全漏洞。
2.Flask-DebugToolbar
Flask-DebugToolbar是另一个非常了不起的工具，它可以帮助在你的应用程序中调试问题。在调试模式下，它会把一个侧边栏置于你的应用程序的每一页上。侧边栏提供了有关SQL查询，日志记录，版本，模板，配置和其它有趣的信息，使得更容易地跟踪问题。
看看快速入门中的调试模式。在Flask官方文档中有一些关于错误处理，日志记录以及使用调试器等不错的信息。
Flask工程配置
当你学习Flask的时候，配置看起来很简单。你只要在config.py中定义一些变量接着一切就能工作了。当你开始必须要管理生产应用的配置的时候，这些简单性开始消失了。你可能需要保护API密钥以及为不同的环境使用不同的配置（例如，开发和生产环境）。在本章节中我们会介绍Flask一些先进的功能，它可以使得管理配置容易些。
简单的例子
一个简单的应用程序可能不会需要任何这些复杂的功能。你可能只需要把config.py放在你的仓库/版本库的根目录并且在app.py或者yourapp/\\_init\\_.py中加载它。
config.py文件中应该每行包含一个配置变量赋值。当你的应用程序初始化的时候，在config.py中的配置变量用于配置Flask和它的扩展并且它们能够通过app.config字典访问到–例如，app.config["DEBUG"]。
DEBUG=True#TurnsondebuggingfeaturesinFlask BCRYPT_LEVEL=12#ConfigurationfortheFlask-Bcryptextension MAIL_FROM_EMAIL="robert@example.com"#Foruseinapplicationemails
配置的变量可以被Flask，它的扩展或者你来使用。这个例子中，每当我们在一封事务性邮件中需要默认的“发件人”的时候，我们可以使用app.config["MAIL_FROM_EMAIL"]–例如，密码重置。把这些信息放置于一个配置变量中使得以后能够容易地修改它。
#app.pyorapp/__init__.pyfromflaskimportFlask
app=Flask(__name__)
app.config.from_object('config')
#Nowwecanaccesstheconfigurationvariablesviaapp.config["VAR_NAME"].
- DEBUG：为你提供了调试错误的一些方便的工具。这包括一个基于Web的堆栈跟踪和交互式的Python控制台。在开发环境中设置成True；生产环境中设置成False。
- SECRET\_KEY：这是Flask用来为cookies签名的密钥。它也能被像Flask-Bcrypt类的扩展使用。你应该在你的实例文件夹中定义它，这样可以远离版本控制。你可以在下一个章节中阅读更多关于示例文件夹的内容。一般情况下这应该是一个复杂的随机值。
- BCRYPT\_LEVEL：如果你使用Flask-Bcrypt来散列用户密码的话，你需要指定一个“循环”数，这个数是在执行散列密码的算法需要的。如果你不使用Flask-Bcrypt，你可以忽略这里。用于散列密码的循环数越大，攻击者猜测密码的时间会越长。同时，循环数越大会增加散列密码的时间。后面我们会给出在Flask应用中使用Bcrypt的一些最佳实践。
确保在生产环境中DEBUG设置成False。如果保留DEBUG为True，它允许用户在你的服务器上执行任意的Python。
实例文件夹
有时候你需要定义包含敏感信息的配置变量。我们想要从config.py中分离这些变量并且让它们保留在仓库/版本库之外。你可能会隐藏像数据库密码以及API密钥的一些敏感信息，或者定义于特定于指定机器的配置变量。为让实现这些要求更加容易些，Flask提供了一个叫做instancefolders的功能。实例文件夹是仓库/版本库下的一个子目录并且包含专门为这个应用程序的实例的一个配置文件。我们不希望它提交到版本控制。
config.py requirements.txt run.py instance/ config.py yourapp/ __init__.py models.py views.py templates/ static/
使用实例文件夹
我们使用app.config.from_pyfile()来从一个实例文件夹中加载配置变量。当我们调用Flask()来创建我们的应用的时候，如果我们设置了instance_relative_config=True，app.config.from_pyfile()将会从instance/目录加载指定文件。
#app.pyorapp/__init__.py
app=Flask(__name__,instance_relative_config=True)
app.config.from_object('config')
app.config.from_pyfile('config.py')
现在我们可以像在config.py中那样在instance/config.py中定义配置变量。你也应该把你的实例文件夹加入到版本控制系统的忽略列表中。要使用Git做到这一点的话，你需要在.gitignore新的一行中添加instance/。
密钥
实例文件夹的隐私性成为在其里面定义不想暴露到版本控制的密钥的最佳候选。这些密钥可能包含了你的应用的密钥或者第三方API密钥。如果你的应用是开源的或者以后可能会公开的话，这一点特别重要。我们通常要求其他用户或者贡献者使用自己的密钥。
#instance/config.py SECRET_KEY='Sm9obiBTY2hyb20ga2lja3MgYXNz' STRIPE_API_KEY='SmFjb2IgS2FwbGFuLU1vc3MgaXMgYSBoZXJv' SQLALCHEMY_DATABASE_URI=\\"postgresql://user:TWljaGHFgiBCYXJ0b3N6a2lld2ljeiEh@localhost/databasename"
基于环境的配置
如果在你的生产环境和开发环境中的差异非常小的话，你可能想要使用实例文件夹来处理配置的变化。定义在'instance/config.py'文件中的配置变量能够覆盖'config.py'中的值。你只需要在'app.config.from_object()'后调用'app.config.from_pyfile()'。这样用法的好处之一就是在不同的机器上修改你的应用的配置。
#config.py DEBUG=False SQLALCHEMY_ECHO=False #instance/config.py DEBUG=True SQLALCHEMY_ECHO=True
在生产环境上，我们略去上面'instance/-config.py'中的配置变量，它会退回到定义在'config.py'中的值。
了解更多关于Flask-SQLAlchemy的配置项。（中文版的位于：http://www.pythondoc.com/flask-sqlalchemy/config.html#configuration-keys)
基于环境变量配置
实例文件夹不应该出现在版本控制中。这就意味着你将无法跟踪你的实例配置的变化。如果只是一、两个变量这可能不是什么问题，但是如果你在不同的环境上（生产，预升级，开发，等等）配置都有些微调话，你就不会想要存在丢失它们的风险。
Flask给我们选择配置文件的能力，它可以基于一个环境变量的值来加载不同的配置文件。这就意味着在我们的仓库/版本库里，我们可以有多个配置文件并且总会加载正确的那一个。一旦我们有多个配置文件的话，我可以把它们移入它们自己config文件夹中。
requirements.txt run.py config/ __init__.py#Empty,justheretotellPythonthatit'sapackage. default.py production.py development.py staging.py instance/ config.py yourapp/ __init__.py models.py views.py static/ templates/
在上面的文件列表中我们有多个不同的配置文件。
- config/default.py：默认的配置值，可用于所有的环境或者被个人的环境给覆盖。
- config/development.py：用于开发环境的配置值。这里你可能会指定本地数据库的URI。
- config/production.py：用于生产环境的配置值。在这里DEBUG一定要设置成False。
- config/staging.py：根据开发进度，你可能会有一个模拟生产环境，这个文件主要用于这种场景。
为了决定要加载哪个配置文件，我们会调用'app.config.from_envvar()'。
#yourapp/\\_\\_init\\_\\_.py
app=Flask(__name__,instance_relative_config=True)
#Loadthedefaultconfiguration
app.config.from_object('config.default')
#Loadtheconfigurationfromtheinstancefolder
app.config.from_pyfile('config.py')
#LoadthefilespecifiedbytheAPP\\_CONFIG\\_FILEenvironmentvariable#Variablesdefinedherewilloverridethoseinthedefaultconfiguration
app.config.from_envvar('APP_CONFIG_FILE')
环境变量的值应该是配置文件的绝对路径。
我们如何设置这个环境变量取决于我们运行应用所在的平台。如果我们运行在一个普通的Linux服务器上，我们可以编写一个设置环境变量的shell脚本并且运行run.py。
#start.sh APP\\_CONFIG\\_FILE=/var/www/yourapp/config/production.py pythonrun.py
start.sh对于每一个环境都是独一无二的，因此它应该被排除在版本控制之外。在Heroku上，我们需要使用Heroku工具来设置环境变量。这种设置方式也适用于其它的PaaS平台。