我知道如何使用virtualenv在长时间运行的脚本中隔离Python依赖项,比如Flask或Twisted应用程序。但是,对于一个打算从命令行调用的脚本,我一直有些困惑。
假设我想要创建一个CLI工具来与某个API交互,可能使用Click或docopt。显然,您不希望每次使用此工具时都必须使用source venv/bin/activate。但我认为,即使在开发之后,最好仍然使用virtualenv来保持环境的整洁。
对于新手的问题,很抱歉,but...what,你应该做什么来打包一个脚本,以便它可以以这种方式干净地使用呢?(我更习惯于RubyGems,并且还在摸索Pip和VirtualEnv。)
发布于 2015-04-22 04:34:21
发布于 2014-10-03 09:36:06
Dabapps写的一篇关于virtualenv的优秀文章会让你明白这一点:http://www.dabapps.com/blog/introduction-to-pip-and-virtualenv-python/
至于从CLI脚本调用它:
将
这样一来,你就不需要每次都获取virtualenv了。
发布于 2014-09-27 11:50:52
每个virtualenv都有自己的Python site_packages、内置模型和Python解释器。因此,virtualenv是在项目级上使用的,而不是在“通过包打包”级。它隔离了Python模块的集合和可能的依赖项。每个virtualenv都有自己的位置,pip将在其中安装包。从理论上讲,virtualenv不应该是必需的,但在实践中,有一种方法可以用不同版本的Python模块和Python解释器拥有不同的“环境”是很好的。我不知道Ruby是否有类似的东西,这会让你对不同的项目有不同的“宝石集”。
直接使用virtualenv的人会在他们的.bashrc中添加别名,例如:
alias workonawesomeproject="source ~/venv/awesomeproject/bin/activate"他们将使用别名激活virtualenv
workonawesomeproject要保留一个虚拟环境,可以使用命令deactivate
处理virtualenvs的一种更简单的方法是使用virtualenvwrapper
pip install virtualenvwrapper
将这些行添加到您的.bashrc (或其他shell初始化文件)中
export WORKON_HOME=$HOME/venv # this directory is your choice
export PROJECT_HOME=$HOME/src # this directory is your choice
source /usr/local/bin/virtualenvwrapper.sh # leave this alone如果你刚刚修改了你的.bashrc,请确保源码
source ~/.bashrc然后,要创建一个新的virtualenv,只需运行
mkvirtualenv awesomeproject要使用该虚拟环境
workon awesomeproject停用该虚拟环境
deactivateVirtualenvwrapper文档:http://virtualenvwrapper.readthedocs.org/en/latest/install.html
https://stackoverflow.com/questions/26071059
复制相似问题