作为部署用户通过 Fabric 激活 virtualenv
我想在本地运行我的结构脚本,这将依次登录到我的服务器,切换用户进行部署,激活项目 .virtualenv,这将更改项目的目录并发出 git pull。
def git_pull():
sudo('su deploy')
# here i need to switch to the virtualenv
run('git pull')
我通常使用 virtualenvwrapper 中的 workon 命令,该命令提供激活文件,而激活后文件会将我放入项目文件夹中。 在这种情况下,似乎因为 Fabric 从 shell 内运行,所以控制权交给了 Fabric,所以我不能使用 bash 的内置源到 '$source ~/.virtualenv/myvenv/bin/activate'
任何人都有他们如何做到这一点的示例和解释?
I want to run my fabric script locally, which will in turn, log into my server, switch user to deploy, activate the projects .virtualenv, which will change dir to the project and issue a git pull.
def git_pull():
sudo('su deploy')
# here i need to switch to the virtualenv
run('git pull')
I typically use the workon command from virtualenvwrapper which sources the activate file and the postactivate file will put me in the project folder. In this case, it seems that because fabric runs from within shell, control is give over to fabric, so I can't use bash's source built-in to '$source ~/.virtualenv/myvenv/bin/activate'
Anybody have an example and explanation of how they have done this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(10)
作为 bitprophet 预测的更新:使用 Fabric 1.0,您可以使用 prefix() 和您自己的上下文管理器。
As an update to bitprophet's forecast: With Fabric 1.0 you can make use of prefix() and your own context managers.
现在,你可以做我所做的,这是笨拙但工作得很好*(这种用法假设你正在使用 virtualenvwrapper ——你应该是 ——但你可以轻松地替换你提到的相当长的“源”调用,如果没有):
从版本 1.0 开始,Fabric 有一个
prefix
上下文管理器 使用此技术,因此您可以例如:* 必然存在使用
command1 && 的情况。 command2
方法可能会让您崩溃,例如当command1
失败时(command2
永远不会运行)或者command1
不运行正确转义并包含特殊的 shell 字符等等。Right now, you can do what I do, which is kludgy but works perfectly well* (this usage assumes you're using virtualenvwrapper -- which you should be -- but you can easily substitute in the rather longer 'source' call you mentioned, if not):
Since version 1.0, Fabric has a
prefix
context manager which uses this technique so you can for example:* There are bound to be cases where using the
command1 && command2
approach may blow up on you, such as whencommand1
fails (command2
will never run) or ifcommand1
isn't properly escaped and contains special shell characters, and so forth.我只是使用一个简单的包装函数 virtualenv() ,可以调用它而不是 run() 。 它不使用 cd 上下文管理器,因此可以使用相对路径。
I'm just using a simple wrapper function virtualenv() that can be called instead of run(). It doesn't use the cd context manager, so relative paths can be used.
virtualenvwrapper
可以使这变得更简单使用 @nh2 的方法(此方法在使用
local
时也有效,但仅适用于workon
的 virtualenvwrapper 安装> 位于$PATH
中,换句话说 -- Windows)或者部署您的 fab 文件并在本地运行它。 此设置允许您激活本地或远程命令的 virtualenv。 这种方法非常强大,因为它解决了
local
无法使用bash -l
运行 .bashrc 的问题:<前><代码>@contextmanager
def local_prefix(shell, 前缀):
def local_call(命令):
return local("%(sh)s \"%(pre)s && %(cmd)s\"" %
{“sh”:shell,“pre”:前缀,“cmd”:命令})
产生本地前缀
def write_requirements(shell="/bin/bash -lic", env="env1"):
使用 local_prefix(shell, "workon %s" % env) 作为本地:
本地(“点冻结>需求.txt”)
write_requirements() # 本地
运行(“fab write_requirements”)
virtualenvwrapper
can make this a little simplerUsing @nh2's approach (this approach also works when using
local
, but only for virtualenvwrapper installations whereworkon
is in$PATH
, in other words -- Windows)Or deploy your fab file and run this locally. This setup lets you activate the virtualenv for local or remote commands. This approach is powerful because it works around
local
's inability to run .bashrc usingbash -l
:这是我在本地部署中使用 virtualenv 的方法。
使用 Fabric 的 path() 上下文管理器可以使用 virtualenv 中的二进制文件运行
pip
或python
。This is my approach on using
virtualenv
with local deployments.Using fabric's path() context manager you can run
pip
orpython
with binaries from virtualenv.感谢发布的所有答案,我想为此添加另一种选择。 有一个模块 fabric-virtualenv 可以提供与相同代码相同的功能:
fabric-virtualenv 使用fabric.context_managers.prefix,这可能是一个好方法:)
Thanks to all answers posted and I would like to add one more alternative for this. There is an module, fabric-virtualenv, which can provide the function as the same code:
fabric-virtualenv makes use of
fabric.context_managers.prefix
, which might be a good way :)如果您想将软件包安装到环境中或想根据环境中的软件包运行命令,我发现这个 hack 可以解决我的问题,而不是编写复杂的结构方法或安装新的操作系统软件包:
这样您可以不需要激活环境,但可以在环境下执行命令。
If you want to install the packages to environment or want to run commands according to the packages you have in environment, I have found this hack to solve my problem, instead of writing complex methods of fabric or installing new OS packages:
This way you might not need to activate the environment, but you can execute commands under the environment.
以下是装饰器的代码,它将导致对任何 run/sudo 调用使用虚拟环境:
然后要使用装饰器,请注意装饰器的顺序很重要:
Here is code for a decorator that will result in the use of Virtual Environment for any run/sudo calls:
and then to use the decorator, note the order of the decorators is important:
这个方法对我有用,你也可以应用这个。
假设 venv 是您的虚拟环境目录,并在适当的地方添加此方法。
This approach worked for me, you can apply this too.
Assuming
venv
is your virtual env directory and add this method wherever appropriate.我将 pyenv 与插件 pyenv-virtualenvwrapper 一起使用。 我在 workon 上没有成功,而是使用这个(fabric 2.5):
对于 git pull 代理转发很好,即。
ssh -A ..
或在~/.ssh/config
中更好,如下所示:现在在开发计算机上,如果您在代理中有私钥(在 < code>ssh-add 或者如果您在进行
git Push
后在~/.ssh/config
中有AddKeysToAgent yes
),那么git pull
不应询问密钥的密码。I use pyenv with plugin pyenv-virtualenvwrapper. I had no success with workon, instead I use this (fabric 2.5):
For
git pull
agent forwarding is good, ie.ssh -A ..
or better in~/.ssh/config
something like this:And now on the development machine if you have a private key in the agent (after
ssh-add
or if you haveAddKeysToAgent yes
in~/.ssh/config
after you madegit push
) thengit pull
should not ask for the passphrase of the key.