我正在尝试编写脚本,它应该使用PortageAPI。但Portage python包在PyPi中不可用,但即使它可用,也没有任何意义,因为它应该在一些配置了包数据库和配置的系统中使用
我试着写了以下足够丑陋的代码:
[tool.poetry.dependencies]
python = "^3.6"
click = "^7.0-r1"
portage = [
{ markers = "python_version ~= '3.6' and sys_platform == 'linux'", path = "/usr/lib64/python3.6/site-packages/portage/" },
{ markers = "python_version ~= '3.7' and sys_platform == 'linux'", path = "/usr/lib64/python3.7/site-packages/portage/" },
{ markers = "python_version ~= '3.8' and sys_platform == 'linux'", path = "/usr/lib64/python3.8/site-packages/portage/" },
{ markers = "python_version ~= '3.9' and sys_platform == 'linux'", path = "/usr/lib64/python3.9/site-packages/portage/" }
]
但它不起作用。路径目录中的代码不被Poetry视为python包
[ValueError]
Directory /usr/lib64/python3.6/site-packages/portage does not seem to be a Python package
有没有办法做到这一点,并将系统用作运行测试的虚拟环境(我知道在主机系统中运行测试不是一个好主意,但有一个安装了Portage的docker映像)
在我看来,这可能与不允许访问系统站点包的虚拟环境有关。如果确实是这样,那么请注意,从今天起,这对于诗歌是不可行的。有一个open issue,也有一个pull request
一种解决方法可能是先创建虚拟环境,而不使用诗歌,例如:
然后在这个虚拟环境中使用诗歌,因为诗歌应该不会创建虚拟环境,因为它可以检测到它正在一个虚拟环境中运行,并将使用它
显然,portage不是一个可安装的pipPython项目,因此指定
markers
和path
很可能是无用的。此外site-packages
目录通常包含已安装的项目,而path
应该指向一个位置,poetry(pip)可以从该位置下载项目的可安装发行版我相信一旦
system-site-packages
的问题得到解决,portage就可以被列为一个简单的依赖项portage = "*"
相关问题 更多 >
编程相关推荐