[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#61701] [PATCH] doc: Propose new cookbook section for reproducible r
From: |
Kyle Andrews |
Subject: |
[bug#61701] [PATCH] doc: Propose new cookbook section for reproducible research. |
Date: |
Wed, 22 Feb 2023 23:21:02 +0000 |
Simon Tournier <zimon.toutoune@gmail.com> writes:
>> +(define python-apted
>> + (package
>> + (name "python-apted")
>> + (version "1.0.3")
>> + (source (origin
>> + (method url-fetch)
>> + (uri (pypi-uri "apted" version))
>> + (sha256
>> + (base32
>> + "1sawf6s5c64fgnliwy5w5yxliq2fc215m6alisl7yiflwa0m3ymy"))))
>> + (build-system python-build-system)
>> + (home-page "https://github.com/JoaoFelipe/apted")
>> + (synopsis "APTED algorithm for the Tree Edit Distance")
>> + (description "APTED algorithm for the Tree Edit Distance")
>> + (license expat)))
>> +
>> +(define last-guix-with-python-3.6
>> + (list
>> + (channel
>> + (name 'guix)
>> + (url "https://git.savannah.gnu.org/git/guix.git")
>> + (commit
>> + "d66146073def03d1a3d61607bc6b77997284904b"))))
>> +
>> +(define connection-to-last-guix-with-python-3.6
>> + (inferior-for-channels last-guix-with-python-3.6))
>
> Why do you need an inferior? Is it to avoid the “guix time-machine”?
> Ah, no the answer below. :-)
>
>> +(define first car)
>> +
>> +(define python-3.6
>> + (first
>> + (lookup-inferior-packages
>> + connection-to-last-guix-with-python-3.6 "python")))
>> +
>> +(define python3.6-numpy
>> + (first
>> + (lookup-inferior-packages
>> + connection-to-last-guix-with-python-3.6 "python-numpy")))
>> +
>> +(define included-packages
>> + (list r r-reticulate))
>> +
>> +(define inferior-packages
>> + (list python-3.6 python3.6-numpy))
>> +
>> +(define package-with-python-3.6
>> + (package-with-explicit-python python-3.6
>> + "python-" "python3.6-" 'python3-variant))
>> +
>> +(define custom-variant-packages
>> + (list (package-with-python-3.6 python-apted)))
>> +
>> +(concatenate-manifest
>> + (map packages->manifest
>> + (list
>> + included-packages
>> + inferior-packages
>> + custom-variant-packages)))
>
> While this is cool, I would not recommend it as some practise. This
> kind of mix can lead to various annoyances, IMHO. First, it will scale
> poorly if you add more inferiors. Second, the probability that the
> resulting computational environment works well decreases.
After experiencing the resulting compile time, I agree. I just don't
know the best way to get a working python variant. I experimented today
with:
```
(use-modules
(guix profiles)
(guix packages)
(gnu packages)
(ice-9 regex)
(gnu packages python)
(guix base32))
(define (origin-nix-hash source)
(bytevector->nix-base32-string
(content-hash-value
(origin-hash source))))
(define-public (change-source source new-uri new-hash new-patches)
(origin
(inherit source)
(uri new-uri)
(sha256
(base32 new-hash))
(patches new-patches)))
(define (python-distribution-uri version)
(string-append "https://www.python.org/ftp/python/"
version "/Python-" version ".tar.xz"))
(define-public python-3.6.8
(define v "3.6.8")
(package
(inherit python-3)
(version v)
(source
(change-source
(package-source python-3.9)
(python-distribution-uri v)
"14qi6n5gpcjnwy165wi9hkfcmbadc95ny6bxxldknxwmx50n4i1m"
(filter
(lambda (patch)
(not (string-match "fix-tests|hurd" patch)))
(origin-patches (package-source python-3.9)))))))
(packages->manifest (list python-3.6.8))
```
However, I ran into issues applying patches which I don't yet understand
how to deal with. It would be really cool if Guix had a command which
showed the state at each step in the process of creating a store
object. Whatever the workflow and tacit knowledge you use to debug these
things, I don't grasp it yet.
>> diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm
>> index c8f04b2298..d4aaab906d 100644
>> --- a/guix/build-system/python.scm
>> +++ b/guix/build-system/python.scm
>> @@ -36,6 +36,7 @@ (define-module (guix build-system python)
>> #:use-module (srfi srfi-1)
>> #:use-module (srfi srfi-26)
>> #:export (%python-build-system-modules
>> + package-with-explicit-python
>> package-with-python2
>> strip-python2-variant
>> default-python
>
> Maybe this could be a separated patch.
That's a good idea. I suppose I could wrap it a bit with
e.g. package-with-python3-variant.