GUIX에서 더 이상 채널에 없는 이전 버전의 패키지를 사용하는 방법은 무엇입니까?

Question 1

세 번째는 매력입니다. 하층민 목록을 사용하는 것이 가장 효과적인 것 같습니다.

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내가 만든 환경을 재현하는 방법을 배운 설명 링크가 있습니다.나의 첫 번째 대답. 섹션에서는 이 내보내기에 채널 정보가 포함되어 있지 않다고 설명하므로 매니페스트에 채널 정보가 전혀 포함되어 있지 않으며 두 번째 파일(나의 두 번째 대답). 설명은 바로 아래에 --export-manifest링크되어 있는데 --export-channels, 기존의 내용을 수정하는 중이었기 때문에 처음에는 읽지 않았습니다 channels.scm. 그러나 자막의 필요성에 대한 설명으로 섹션이 끝납니다.

--manifest설명 의 일부가 guix package매니페스트에서 직접 채널을 정의하는 것일 수 있다면 이해하기가 더 쉬울 것입니다.

제가 올바르게 이해했다면 열등함은 기술적으로 채널과 다르기 때문에 위의 마지막 문장이 잘못되었으며 매니페스트에서 채널을 정의할 수 없습니다. 그러나 실제로는 매니페스트의 모든 패키지에 하위 패키지를 사용하여 매니페스트의 채널을 효과적으로 하드코딩하는 것이 가능해 보입니다. 이로 인해 매니페스트에서 직접 채널 사양을 허용하는 것이 더 간단한지 궁금합니다.

질문에 대한 답변에서 이 솔루션은 문제를 촉발한 원래 문제인 running 을 해결하기에는 여전히 충분하지 않습니다. 원래 채널의 솔루션이 여전히 사용되고 있기 docker-compose때문입니다 . 가능한docker-composepython-pyyaml패키지가 열등한 입력을 사용하도록 허용modify-inputs. 이렇게 하면 열악한 오래된 프로필을 docker-compose사용 하고 나머지 프로필에서는 원래 채널의 최신 프로필을 사용할 수 있습니다 .python-pyyamlpython-pyyaml

Answer

세 번째는 매력입니다. 하층민 목록을 사용하는 것이 가장 효과적인 것 같습니다.

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내가 만든 환경을 재현하는 방법을 배운 설명 링크가 있습니다.나의 첫 번째 대답. 섹션에서는 이 내보내기에 채널 정보가 포함되어 있지 않다고 설명하므로 매니페스트에 채널 정보가 전혀 포함되어 있지 않으며 두 번째 파일(나의 두 번째 대답). 설명은 바로 아래에 --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명령?)

편집: 이 솔루션이 좋지 않은 또 다른 이유는 다음과 함께 작동하지 않는다는 것입니다 --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