Subject: Re: [bug#61701] [PATCH] doc: Propose new cookbook section for reproducible research.

From: Kyle Andrews <[email-masked]>
Date: Wed, 22 Feb 2023 23:21:02 +0000

Simon Tournier <[email-masked]> 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.