☰

GUIXでこれ以上チャンネルにない古いバージョンのパッケージを使用するには？

tag-icon • tag-icon guix
GUIXでこれ以上チャンネルにない古いバージョンのパッケージを使用するには？

私をGUIXに魅了した理由の1つは、お互いに邪魔することなく、さまざまなバージョンのパッケージを同時に「インストール」できることでした。しかし、実際にこれらのさまざまなバージョンを使用する方法がわかりません。

たとえば、最近この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について特に気にしません。むしろ、この質問は、これをGUIXの基本ツールに置き換えようとする旅の一部です。

（また、pyyaml 6はユーザーにいくつかのセキュリティ機能を強制するため、pyyaml 5はもう使用しないでください。pyyamlは例としてのみ使用されます。）

ベストアンサー1

3番目は魅力です。下層民のリストを使うのが一番効果的だそうです。

info guix Inferiors詳細より。情報ページのスナップショット。 （興味深いことに、彼らのユースケースは私のユースケースと非常によく似ています。つまり、以前のバージョンのyamlライブラリをPythonインタプリタとして使用するのではなく、古いバージョンのjsonライブラリをトリックインタプリタとして使用することです）。

     Note: The functionality described here is a “technology preview” as
     of version 0.0-git.  As such, the interface is subject to change.

   Sometimes you might need to mix packages from the revision of Guix
you’re currently running with packages available in a different revision
of Guix.  Guix “inferiors” allow you to achieve that by composing
different Guix revisions in arbitrary ways.

   ...

   When combined with channels (*note Channels::), inferiors provide a
simple way to interact with a separate revision of Guix.  For example,
let’s assume you want to install in your profile the current ‘guile’
package, along with the ‘guile-json’ as it existed in an older revision
of Guix—perhaps because the newer ‘guile-json’ has an incompatible API
and you want to run your code against the old API.  To do that, you
could write a manifest for use by ‘guix package --manifest’ (*note
Invoking guix package::); in that manifest, you would create an inferior
for that old Guix revision you care about, and you would look up the
‘guile-json’ package in the inferior.

引き続き例を挙げましょう。以下は、この特定のユースケースの同じ例です。

$ cat mypyyamlmanifest.scm
(use-modules (guix inferior) (guix channels)
             (srfi srfi-1))

(define channels
  (list (channel
         (name 'guix)
         (url "https://git.savannah.gnu.org/git/guix.git")
         (commit
          ;; The commit with the python-pyyaml 5.4.1
          "d3e1a94391a838332b0565d56762a58cf87ac6b1"))))

(define inferior
  (inferior-for-channels channels))

(packages->manifest
 (list (first (lookup-inferior-packages inferior "python-pyyaml"))
       (specification->package "python")))

$ guix shell -m mypyyamlmanifest.scm 
...

$ python3 -c "import yaml; print(yaml.__version__)"
5.4.1

この情報を見つけるのになぜそれほど長い時間がかかったのか考えてみましょう。 （たぶんGUIX開発者はこの記事を読んで、私はそれを使ってドキュメントにパッチを提供するかもしれません。）

guix info guix packageこれがチェックリスト使用の出発点です。説明には--manifestリストの作成方法の簡単な例がありますが、ディスカッションチャネルはありません。--export-manifest私が作成した環境を再現する方法を学んだ説明リンクがあります。私の最初の答え。このセクションでは、このエクスポートにチャンネル情報が含まれていないと説明しているため、マニフェストにチャンネル情報がまったく含まれていないため、2番目のファイル（私の2番目の答え）。説明はすぐ下に--export-manifestリンクされていますが--export-channels、既存の内容を修正していたので、最初は読みませんでしたchannels.scm。しかし、字幕の必要性の説明でセクションが終わります。

--manifest説明の一部がguix packageマニフェストから直接チャンネルを定義することである場合は、理解しやすくなります。

私が正しく理解していると、劣等は技術的にチャンネルとは異なるため、上記の最後の文は間違っており、マニフェストでチャンネルを定義することはできません。しかし、実際には、マニフェストのすべてのパッケージにサブパッケージを使用して、マニフェストのチャネルを効果的にハードコーディングすることが可能になります。これにより、マニフェストで直接チャンネル仕様を許可する方が簡単なのかと思います。

質問への答えでは、このソリューションは問題を引き起こした元の問題であるrunningを解決するのに十分ではありません。元のチャンネルのソリューションがまだ使用されているdocker-composeからです。可能docker-composepython-pyyamlパッケージに劣った入力を使用させるmodify-inputs。これにより、古い古いプロファイルがdocker-compose使用され、残りのプロファイルでは元のチャンネルの最新プロファイルを使用できます。python-pyyamlpython-pyyaml

おすすめ記事