出于持续集成的目的,我使用了以下内置的py3.6 venv命令(不要与virtualenv混淆)(参见pep 405)。
python -m venv --system-site-packages --without-pip <ENVNAME>
我发现它工作得很好,我马上就得到了一个环境。
但是,.... venv生成一个pyvenv.cfg文件,如下所示:
home = absolute/path/to/prefix/of/interpreter/which/ran/venv
include-system-site-packages = true
version = <interpreter python version>
这个文件包含了一个非常重要的home键,它引用了创建venv的原始的python库。非常重要的是,一个无效的home键**会使python进程崩溃,因为它在库解释器中找不到它的库。
现在我想把这个“测试过的绿色”venv +它的基础python部署到生产机器上。我不想在生产系统上重建它,而只是把它复制到那里。
不用说,在CI工具上创建的home绝对路径在生产机器上是无效的,所以我需要编辑pyvenv.cfg文件home key,一切都很顺利。
这个文件操作是我真正想避免的步骤,因为我想生成一个只需要复制、激活和调用(标准方式)的工件。
我尝试将%xyz%,$xyz甚至configParser %(xyz)s放到原始文件中,但这些都无法解析。我还尝试在那里使用相对路径,但该路径是相对于工作目录的,我不想强制生产系统从固定的工作目录调用我的工件。
除了丑陋的pyvenv.cfg操作之外,是否还有其他解决方案?
4条答案
按热度按时间f45qwnt81#
在窗口中:
将以下代码添加到
activate.bat
,以便在每次运行之前动态生成pyvenv.cfg
。pyvenv_温度.配置文件数据:
bvhaajcl2#
根据Creation of virtual environments中的规格,您不需要激活venv。
您不需要特别激活环境;activation只是把虚拟环境的二进制目录放在你的路径前面,这样"python"就可以调用虚拟环境的Python解释器,你可以运行安装的脚本而不必使用它们的完整路径。然而,所有安装在虚拟环境中的脚本都应该是可以运行的,而不需要激活它,并且可以自动运行虚拟环境的Python。
Linux示例:
MS Windows示例:
7rtdyuoh3#
问题有点旧,但找到了有效的解决方案。将以下内容添加到
activate.bat
文件中。v440hwme4#
你可以在GitHub中基于Django的项目库中找到通用的解决方案,这些项目库将所有需要的模块存储在一个文本文件requirements.txt中,而不是modules目录中。当其他人或生产服务器需要它们时,他们可以从pypi下载requirements.txt中的模块。所以你所需要的就是从Yirtualenv生成requirements.txt文件,然后将此文件提交给SCM。