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

Question 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

Answer

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

Question 2

素晴らしいinfo guixページをご提供いただきありがとうございます。これが可能だと思います。

guix shell \
    --with-git-url=python-pyyaml="https://github.com/yaml/pyyaml.git" \
    --with-branch=python-pyyaml="release/5.4.1" \
    python-pyyaml python

しかし、すでに完璧なパッケージ定義がある場合は、少し奇妙な感じがします。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コマンド？）

編集：この解決策が悪いもう1つの理由は、次のように動作しないことです--export-manifest。

$ guix shell \
    --with-git-url=python-pyyaml="https://github.com/yaml/pyyaml.git" \
    --with-branch=python-pyyaml="release/5.4.1" \
    --export-manifest \
    python-pyyaml python > mymanifest.scm

$ guix shell -m mymanifest.scm
guix shell: error: the source of [email protected] is not a Git

そしてmymanifest.scm：

$ cat mymanifest.scm
;; What follows is a "manifest" equivalent to the command line you gave.
;; You can store it in a file that you may then pass to any 'guix' command
;; that accepts a '--manifest' (or '-m') option.

(use-modules (guix transformations))

(define transform1
  (options->transformation
    '((with-git-url
        .
        "python-pyyaml=https://github.com/yaml/pyyaml.git")
      (with-branch . "python-pyyaml=release/5.4.1"))))

(packages->manifest
  (list (transform1
          (specification->package "python-pyyaml"))
        (transform1 (specification->package "python"))))

Answer