出于持续集成的目的，我使用以下内置 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。非常重要的是，无效的主页键会导致在基本解释器中找不到其库的 python 进程崩溃。
现在我想将这个“经过测试的绿色”venv + 其基础 python 部署到生产机器上。我不想在生产系统上重建它，而只是将它复制到那里。
不用说，在 CI 工具上创建的主页绝对路径在生产机器上无效，所以我需要编辑 pyvenv.cfg 文件主页键，一切都像魅力一样工作。
这种文件操作是我真正想避免的步骤，因为我想生成一个只需要复制、激活和调用（标准方式）的工件。
我试图将 %xyz%、$xyz 甚至 configParser %(xyz)s 放在原始文件上，但这些都没有解决。我还尝试在那里使用相对路径，但该路径是相对于工作目录的，我不想强制生产系统从固定工作目录调用我的工件。
除了丑陋的 pyvenv.cfg 操作之外，还有其他解决方案吗？
微服务就是将您的系统分解为单独的组件.但是,系统中的某些东西看起来像是集中式的.我关心的是系统设置.在一个整体中,你有一个大文件/ db,包含所有参数,设置和首选项.这可以更新,备份,恢复,导出,导入等(想想Windows注册表).除此之外,您的客户习惯于前往这个"地方"并设置系统.对于微服务架构,这种"集中制"似乎是一种反模式.
处理这种矛盾的机制/框架是什么？
背景
我有两个python项目.项目A和项目B.
每个项目都有自己的虚拟环境和自己的setup.py.
这两个项目都不是纯py文件,并且具有"构建"过程,如构建扩展,生成源等.
A依赖于B(B上的setup.py install_requires点).
每个项目都作为一个轮子构建和发布/分发到pypi内部部署存储库.
pip install w/wo -e(项目A的开发模式),很好地将项目B安装到项目A venv站点包中.
到目前为止,一切都运行良好,"按书".
现在,我的故事变得复杂......
我想一起开发这两个项目,而不必按顺序A发布B来使用它.
例如,我想:
我实际上想要项目A的pip install -e也可以在开发模式下安装项目B.
经过一些阅读后,我理解(希望是正确的)可以通过--find-links标志将"分发"定义为本地源文件夹.
我在--find-links中定义了项目B根文件夹.
我尝试了(在项目A setup.py文件夹上):
点子安装.-e --find-links = file:/// path/to/B.
点子安装.-e --find-links = git + file:// path/to/B.
两者都没用.
BTW,在通往B轮或B蛋的路径中,
例如:pip安装.-e --find-links = file:///path/to/B.whl
确实有效,但这不是我想要的.
希望你还在我身边:-)(对于这个乏味的故事感到抱歉)
我错过了什么？
TX