在 Windows 上的 Fabric 中运行 local() 命令
自从升级 Fabric 以来,我注意到 Windows 上的 local() 命令出现了一些奇怪的行为(我这样做是因为 local 不起作用)。我的 fabfile 的相关部分如下所示:
env.hosts = ['server.com:22'] # One or multiple server addresses in format ip:port
env.path = '/code'
env.apache_path = '/apache'
env.user = 'user'
env.prj_name = 'user'
env.password = 'password'
def test():
local('python manage.py test measurements temperature results', capture=False)
运行 fab test 用于触发典型的 Django 测试套件。在我的 Mac 上仍然如此。在 Windows 上,它现在声称运行该命令,然后在没有实际测试的情况下停止。如果我将环境信息移动到命令中(或只是将其删除),fab test
将按预期工作。应该是这样吗? env 字典会影响 local() 吗?
Windows 7 上的 Fabric 1.3.3,32 位 Python
I've noticed some strange behavior in the local() command on Windows since upgrading Fabric (which I did because local wasn't working). The relevant bit of my fabfile looks like this:
env.hosts = ['server.com:22'] # One or multiple server addresses in format ip:port
env.path = '/code'
env.apache_path = '/apache'
env.user = 'user'
env.prj_name = 'user'
env.password = 'password'
def test():
local('python manage.py test measurements temperature results', capture=False)
Running fab test
used to fire off the typical Django test suite. It still does on my Mac. On Windows, it now claims to run the command and then stops with no actual testing. If I move the env information into a command (or just delete it), fab test
works as expected. Should this be the case? Does the env dictionary affect local()?
Fabric 1.3.3 on Windows 7, 32-bit Python
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当调用
local
函数时,传递的命令实际上被包装并以不同env
变量中找到的内容为前缀(其中之一,我在问题中看到,是env.path
)。因此,最终执行的命令并不完全是传递的命令,并且可能存在某些配置导致命令失败。要解决这种情况,请使用
--show=debug
确保真正执行的命令是什么:一旦您确切地知道执行的命令,您就可以重现问题并找出真正发生的情况在引擎盖下。
When a
local
function is called, the command that is passed is actually wrapped and prefixed with what is found in differentenv
variables (one of them, that I see in the question, isenv.path
). Hence, the command that is finally executed, isn't exactly the command that was passed and there might be some configuration there that makes the command to fail.To troubleshout this situation, make sure about what's the command that is really being executed using
--show=debug
:Once you know exactly the command executed, you can probably reproduce the problem and find out what's really happening under the hood.