GUIX 吸引我的部分原因是可以同时“安装”各种不同版本的软件包,而不会相互干扰。但我不知道如何实际使用这些不同的版本。
例如,最近,该pyyaml
软件包已从 5.4.1 升级到 6.0。由于各种原因,我想继续使用 5.4.1。(我只是在这里使用 pyyaml 作为示例。)我的商店中确实有旧版本:
$ ls -d1 /gnu/store/*pyyaml*
/gnu/store/22v8l25b33vs65wjd9ap28n772bvlih3-python-pyyaml-5.4.1/
/gnu/store/2j2s1jd6y8x7mlqjp968955misx1qw1c-python-pyyaml-6.0/
/gnu/store/54imz4x65s3xbjrgrfswgk815gfkhk4b-python-pyyaml-5.4.1/
/gnu/store/6537a8na1rbilffqqi642q0lipqfi2zg-python-pyyaml-5.4.1.drv
/gnu/store/6flrrmhq203vg6awdw7r2lsmzix4g2rh-python-pyyaml-6.0-guile-builder
/gnu/store/73k3qdz9rdh64pl7a0f0951zm2pbx5s2-python-pyyaml-5.4.1.drv
/gnu/store/7bcbwi93ihz8v2sdzmj6l9vhjqaxr14l-python-pyyaml-5.4.1-builder
...
如何使用这些旧版本?
仅单独使用这样的旧版本就可以了。例如,我希望这样的事情可以工作:
$ guix shell "[email protected]" python
guix shell: error: python-pyyaml: package not found for version 5.4.1
预计会出现此错误,因为旧版本在我的频道中不可用。所以也许有可能以某种方式指定要使用的旧版本的频道,但我不知道如何。
关于 XY 问题的侧节点,这个问题的直接原因是 docker-compose 现在不再工作了:
$ guix shell docker-compose
guix shell: error: build of `/gnu/store/8qhvnw5mwra9i6ji24xlywcpdl0rdznn-docker-compose-1.29.2.drv' failed
$ zcat /var/log/guix/drvs/8q/hvnw5mwra9i6ji24xlywcpdl0rdznn-docker-compose-1.29.2.drv.gz
...checking requirements: ERROR: docker-compose==1.29.2 ContextualVersionConflict(PyYAML 6.0 (/gnu/store/igfl4023dzvl8vi6xs1m96lcsr4fdw07-python-pyyaml-6.0/lib/python3.9/site-packages), Requirement.parse('PyYAML<6,>=3.10'), {'docker-compose'})
但是,我并不特别关心 docker-compose (wrt this question)。如果有的话,这个问题是我用 GUIX 原生工具替换它的旅程的一部分。
(另外,我知道 pyyaml 6 会强制其用户使用一些安全功能,因此不应再使用 pyyaml 5;pyyaml 仅用作示例。)
第三次是魅力,使用低级的清单似乎是最好的。
详情请参阅
info guix Inferiors
。这是信息页面的快照。(有趣的是,他们的用例与我的非常相似:为 guile 解释器使用旧版本的 json 库,而不是为 python 解释器使用旧版本的 yaml 库。)它继续举一个例子。以下是适用于此特定用例的相同示例:
反思为什么要花这么长时间才能找到这些信息。(也许 GUIX 开发人员会读到这个,也许我可以用它自己为文档提供补丁。)
guix info guix package
是我使用清单的起点。描述中有关于如何制作清单的--manifest
简短示例,并且没有谈论渠道。有一个链接指向--export-manifest
我遵循的描述,以了解如何重新创建为我的第一个答案创建的环境。该部分解释说此导出不包含频道信息,这使我得出结论,清单根本不包含频道信息,并且需要第二个文件(我的第二个答案)。--export-manifest
描述链接到它的--export-channels
正下方,起初我没有阅读,因为我只是调整了我现有的channels.scm
. 但是,该部分最终解释了需要劣等者。--manifest
如果部分guix package
解释可以直接在清单中定义通道,我可能会更容易理解。如果我理解正确,劣质在技术上与渠道不同,所以上面的最后一句话是错误的,不可能在清单中定义渠道。然而在实践中,似乎可以只对清单中的所有包使用劣质包,从而有效地对清单中的通道进行硬编码。这让我想知道直接在清单中允许通道规范是否更简单。
在回答问题时,这个解决方案仍然不足以解决触发问题的初始问题: running
docker-compose
,因为docker-compose
仍然使用python-pyyaml
来自原始频道的。可以让包使用劣质作为输入,使用modify-inputs
. 这使得只docker-compose
使用劣质频道中的过时频道成为可能python-pyyaml
,而让配置文件的其余部分使用python-pyyaml
原始频道中较新的频道。感谢出色的
info guix
页面,我认为这是可行的:但是,如果https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/python-xyz.scm?h=d3e1a94391a838332b0565d56762a58cf87ac6b1# n3907。
如,
pyyaml
是一个非常简单的包,它很好地托管在 github 上,遵循标准的 git 分支和 Python 安装程序。但是有些包可能更复杂,这样简单的替换可能不起作用。是否有某种方法可以在通道 git url 上指定特定提交以用于包?(或者一个完整的
guix shell
命令?)编辑:这个解决方案不好的另一个原因是它不适用于
--export-manifest
:与
mymanifest.scm
:这可能更 GUIXy:
但这有两个缺点:
mypyyamlprofile
,mypyyamlprofile-1-link
)来重新创建相同的环境。不工作的转换解决方案只需要 1 个清单文件和 1 个 guix shell 命令。有没有办法将通道和清单文件组合成一个单一的东西,然后可以用来在一个命令中实例化一个 shell?编辑:显然劣质将允许混合和匹配更容易: