Naming scheme for Python packages

Naming scheme for Python packages

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> commit 89114f39e4be7ac655fbdd7f00a5f985c8f4ce6b
> Author: Andreas Enge <andreas@enge.fr>
> Date:   Wed Sep 4 22:12:33 2013 +0200
>
>     gnu: python: Implement the python naming scheme for pytz and babel.
>     
>     * gnu/packages/python.scm (pytz): Rename this ...
>     * gnu/packages/python.scm (python-pytz): ... to this
>     * gnu/packages/python.scm (python2-pytz): New variable, input python-2.
>     * gnu/packages/python.scm (babel): Rename this ...
>     * gnu/packages/python.scm (python-babel): ... to this
>     * gnu/packages/python.scm (python2-babel): New variable, input python-2.

I think I wasn’t clear when we discussed the policy: I think package
names must be prefixed by “python-”.  By “package name” I mean the
‘name’ field of packages, which is what is exposed to the users.

However, I don’t think that scheme should be followed for variable
names: it’s tedious to type, and Guile offers mechanisms to
select/rename bindings imported from other bindings.

Thus I would do:

  (define pytz
    (package
      (name "python-pytz")
      ...))

WDYT?

Ludo’.

Re: Naming scheme for Python packages

[Cyril Roelandt]

On 09/04/2013 10:51 PM, Ludovic Courtès wrote:
> Andreas Enge <andreas@enge.fr> skribis:
>
>> commit 89114f39e4be7ac655fbdd7f00a5f985c8f4ce6b
>> Author: Andreas Enge <andreas@enge.fr>
>> Date:   Wed Sep 4 22:12:33 2013 +0200
>>
>>      gnu: python: Implement the python naming scheme for pytz and babel.
>>
>>      * gnu/packages/python.scm (pytz): Rename this ...
>>      * gnu/packages/python.scm (python-pytz): ... to this
>>      * gnu/packages/python.scm (python2-pytz): New variable, input python-2.
>>      * gnu/packages/python.scm (babel): Rename this ...
>>      * gnu/packages/python.scm (python-babel): ... to this
>>      * gnu/packages/python.scm (python2-babel): New variable, input python-2.
>
> I think I wasn’t clear when we discussed the policy: I think package
> names must be prefixed by “python-”.  By “package name” I mean the
> ‘name’ field of packages, which is what is exposed to the users.
>
> However, I don’t think that scheme should be followed for variable
> names: it’s tedious to type, and Guile offers mechanisms to
> select/rename bindings imported from other bindings.
>
> Thus I would do:
>
>    (define pytz
>      (package
>        (name "python-pytz")
>        ...))
>

This is quite Debianish. I like it.


Cyril.

Re: Naming scheme for Python packages

[Cyril Roelandt]

On 09/04/2013 10:51 PM, Ludovic Courtès wrote:
> Thus I would do:
>
>    (define pytz
>      (package
>        (name "python-pytz")
>        ...))

And what should we call python2-pytz ?

Cyril.

Re: Naming scheme for Python packages

[Andreas Enge]

On Wed, Sep 04, 2013 at 10:51:17PM +0200, Ludovic Courtès wrote:
> However, I don’t think that scheme should be followed for variable
> names: it’s tedious to type, and Guile offers mechanisms to
> select/rename bindings imported from other bindings.
> Thus I would do:
>   (define pytz
>     (package
>       (name "python-pytz")
>       ...))

Well, we also have the policy so far that variable name = name field.
I find it consistent, and do not mind typing a few "python-" more or less.
It is not what makes packaging quite a bit of work...

But if others agree, this can still be changed quite easily.

You may wish to suggest a patch to the "packaging guidelines" in the documen-
tation; the ease or lack of ease to formulate a coherent guideline could be
an indication on what we should do...

Andreas

Re: Naming scheme for Python packages

[Andreas Enge]

On Wed, Sep 04, 2013 at 10:52:08PM +0200, Cyril Roelandt wrote:
>   (define pytz
>     (package
>       (name "python-pytz")
>       ...))

> This is quite Debianish. I like it.

But the alternative (as I suggested in the packaging guidelines) is as
debianish:

>   (define python-pytz
>     (package
>       (name "python-pytz")
>       ...))

We agree on the outer experience, the question is now how to name variables
internally (which is, admittedly, less important).

Andreas

Re: Naming scheme for Python packages

[Andreas Enge]

Apparently, I am getting tired. Especially the variable names must be
distinct: There is python-pytz (as a module for python=python-3) and
python2-pytz (as a module for python-2) inside the same scheme module.

Unless we wish to create scheme modules python2 and python3, which
I find rather awkward. And if we end up using renamers, it all boils
down to the same thing again.

Andreas

Re: Naming scheme for Python packages

[Andreas Enge]

On Wed, Sep 04, 2013 at 11:07:44PM +0200, Cyril Roelandt wrote:
> And what should we call python2-pytz ?

The pytz module compiled with python-2 and installed into
lib/python2.7/site-packages/, as opposed to the same module compiled
with the default python-3. Compare python-unidecode and python3-unidecode
in debian, for instance.

See Section 6.3.4 of the manual.

Andreas
 

Re: Naming scheme for Python packages

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> Apparently, I am getting tired. Especially the variable names must be
> distinct: There is python-pytz (as a module for python=python-3) and
> python2-pytz (as a module for python-2) inside the same scheme module.

Oh, good point.  Well, OK then.

(In guile.scm we used a different convention: ‘guile-reader/guile-1.8’
vs. ‘guile-reader/guile-2.0’, where ‘/’ reads as ‘over’; the ‘name’
field follows a weird convention.)

BTW, I haven’t check whether this is the case already, but we need
something like

  (define (package-with-explicit-python p python)
    ;; Return a version of P built for PYTHON.
    (package (inherit p) ...))

so we can just write:

  (define python2-pytz
    (package-with-explicit-python python-pytz python-2))

Ludo’.

Re: Naming scheme for Python packages

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On Thu, Sep 05, 2013 at 03:00:27PM +0200, Ludovic Courtès wrote:
> BTW, I haven’t check whether this is the case already, but we need
> something like
>   (define (package-with-explicit-python p python)
>     ;; Return a version of P built for PYTHON.
>     (package (inherit p) ...))
> so we can just write:
>   (define python2-pytz
>     (package-with-explicit-python python-pytz python-2))

The attached patch does almost this, following our offline discussion on
how to create packages recursively on the fly:
- It adds an argument pair "#:python ,python-2", or replaces an already
  present argument "#:python something-else", and this recursively
  for all inputs and native-inputs that use the python build system.
- It rewrites the corresponding names from "python-..." to "python2-...",
  or adds a prefix "python2-".
So one can write
(define python2-pytz
  (package-with-explicit-python python-pytz))
As the second argument would always be python-2, I decided to drop it.

When trying this with python2-babel, the previous code in python.scm
(commented out in the attached patch) and the new one create almost the same
derivations, that differ only in
  /nix/store/4rrnwqsj8c086zzviyypr4fikb7pz49v-python2-babel-0.9.6-guile-builder
vs.
  /nix/store/5prbhg600qa9k8p0bgjs12p4dm682gn8-python2-babel-0.9.6-guile-builder
so that the final hash is also different.

Comments are welcome.

Andreas


[-- Attachment #2: patch.python --]
[-- Type: text/plain, Size: 4444 bytes --]

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index ce89281..aa2d15c 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -28,6 +28,7 @@
   #:use-module (gnu packages patchelf)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix utils)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system python)
   #:use-module (guix build-system trivial))
@@ -215,9 +216,7 @@ using Python 2.4 or higher and provides access to the Olson timezone database.")
     (license x11)))
 
 (define-public python2-pytz
-  (package (inherit python-pytz)
-    (name "python2-pytz")
-    (arguments (append (package-arguments python-pytz) `(#:python ,python-2)))))
+  (package-with-python2 python-pytz))
 
 (define-public python-babel
   (package
@@ -233,7 +232,8 @@ using Python 2.4 or higher and provides access to the Olson timezone database.")
         "03vmr54jq5vf3qw6kpdv7cdk7x7i2jhzyf1mawv2gk8zrxg0hfja"))))
     (build-system python-build-system)
     (inputs
-     `(("python-pytz" ,python-pytz)))
+     `(("python-pytz" ,python-pytz)
+       ("openssl" ,openssl)))
     (arguments `(#:tests? #f)) ; no test target
     (home-page "http://babel.edgewall.org/")
     (synopsis
@@ -246,9 +246,12 @@ access to various locale display names, localized number and date formatting,
 etc. ")
     (license bsd-3)))
 
+;; (define-public python2-babel
+;;   (package (inherit python-babel)
+;;     (name "python2-babel")
+;;     (inputs
+;;      `(("python2-pytz" ,python2-pytz)))
+;;     (arguments (append (package-arguments python-babel) `(#:python ,python-2)))))
+
 (define-public python2-babel
-  (package (inherit python-babel)
-    (name "python2-babel")
-    (inputs
-     `(("python2-pytz" ,python2-pytz)))
-    (arguments (append (package-arguments python-babel) `(#:python ,python-2)))))
+  (package-with-python2 python-babel))
diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm
index 7ac93b2..a704d35 100644
--- a/guix/build-system/python.scm
+++ b/guix/build-system/python.scm
@@ -41,6 +41,56 @@
   (let ((python (resolve-interface '(gnu packages python))))
     (module-ref python 'python-wrapper)))
 
+(define (default-python2)
+  "Return the default Python 2 package."
+  (let ((python (resolve-interface '(gnu packages python))))
+    (module-ref python 'python-2)))
+
+(define-public (package-with-python2 p)
+  "Create a package with the same fields as P, which is assumed to use
+PYTHON-BUILD-SYSTEM and to be compiled with the default python, such that
+it is compiled with python 2 instead.  The name of P is prefixed with
+\"python2-\"; a potential existing prefix \"python-\" is dropped."
+  (let ((rewrite (lambda (x)
+                   ;; procedure taking a two-element list ("name" package)
+                   ;; and returning a two element list
+                   ;; ("name" (package-with-python2 package))
+                   (let ((name (car x))
+                         (content (car (cdr x))))
+                     (list name
+                           (if (package? content)
+                               (package-with-python2 content)
+                               content)))))
+        (build-system (package-build-system p)))
+    (package (inherit p)
+      (name
+        (let ((name (package-name p)))
+          (if (eq? build-system python-build-system)
+            (string-append "python2-"
+                           (if (string-prefix? "python-" name)
+                               (substring name 7)
+                               name))
+            name)))
+      (arguments
+        (let ((arguments (package-arguments p))
+              (python2 (default-python2)))
+          (if (eq? build-system python-build-system)
+            (if (member #:python arguments)
+                (substitute-keyword-arguments arguments ((#:python p) python2))
+                (append arguments `(#:python ,python2)))
+            arguments)))
+      (inputs
+        (let ((inputs (package-inputs p)))
+          (if (null? inputs)
+              '()
+              (map rewrite inputs))))
+      (native-inputs
+        (let ((native-inputs (package-native-inputs p)))
+          (if (null? native-inputs)
+              '()
+              (map rewrite native-inputs)))))))
+
+
 (define* (python-build store name source inputs
                        #:key
                        (python (default-python))

Re: Naming scheme for Python packages

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Thu, Sep 05, 2013 at 03:00:27PM +0200, Ludovic Courtès wrote:
>> BTW, I haven’t check whether this is the case already, but we need
>> something like
>>   (define (package-with-explicit-python p python)
>>     ;; Return a version of P built for PYTHON.
>>     (package (inherit p) ...))
>> so we can just write:
>>   (define python2-pytz
>>     (package-with-explicit-python python-pytz python-2))
>
> The attached patch does almost this, following our offline discussion on
> how to create packages recursively on the fly:
> - It adds an argument pair "#:python ,python-2", or replaces an already
>   present argument "#:python something-else", and this recursively
>   for all inputs and native-inputs that use the python build system.
> - It rewrites the corresponding names from "python-..." to "python2-...",
>   or adds a prefix "python2-".

Great!

> So one can write
> (define python2-pytz
>   (package-with-explicit-python python-pytz))
> As the second argument would always be python-2, I decided to drop it.

Still it’s better to keep it, as a generic version.  Then, we can have:

  (define package-with-python-2
    (cut package-with-explicit-python <> python-2))

and then use that as needed.

> +(define-public (package-with-python2 p)
> +  "Create a package with the same fields as P, which is assumed to use
> +PYTHON-BUILD-SYSTEM and to be compiled with the default python, such that
> +it is compiled with python 2 instead.  The name of P is prefixed with
> +\"python2-\"; a potential existing prefix \"python-\" is dropped."
> +  (let ((rewrite (lambda (x)
> +                   ;; procedure taking a two-element list ("name" package)
> +                   ;; and returning a two element list
> +                   ;; ("name" (package-with-python2 package))
> +                   (let ((name (car x))
> +                         (content (car (cdr x))))
> +                     (list name
> +                           (if (package? content)
> +                               (package-with-python2 content)
> +                               content)))))
> +        (build-system (package-build-system p)))

Sylistic note: never use ‘car’, ‘cdr’, and co; use ‘match’ instead: it
leads to code that is both more readable and more robust (info "(guile)
Pattern Matching").  In that case, you can even use ‘match-lambda’,
which is equivalent to:

  (lambda (x)
    (match x
      ...))

Second remark: inputs are actually tuples of one of two forms:

  (name package)
  (name package output)

The first form means that we take the default output of PACKAGE; the
second form specifies that we want OUTPUT of PACKAGE.  This makes a
different for multiple-output packages, such as ‘libtool’ (info "(guix)
Packages with Multiple Outputs").

So the ‘rewrite’ procedure must look like this:

  (define rewrite
    (match-lambda
      ((name package)
       ...)
      ((name package output)
       ...)))

> +    (package (inherit p)
> +      (name
> +        (let ((name (package-name p)))
> +          (if (eq? build-system python-build-system)
> +            (string-append "python2-"
> +                           (if (string-prefix? "python-" name)
> +                               (substring name 7)
> +                               name))
> +            name)))
> +      (arguments
> +        (let ((arguments (package-arguments p))
> +              (python2 (default-python2)))
> +          (if (eq? build-system python-build-system)
> +            (if (member #:python arguments)
> +                (substitute-keyword-arguments arguments ((#:python p) python2))
> +                (append arguments `(#:python ,python2)))
> +            arguments)))

Please fix the indentation of the ‘if’ arms.

> +      (inputs
> +        (let ((inputs (package-inputs p)))
> +          (if (null? inputs)
> +              '()
> +              (map rewrite inputs))))

(map rewrite (package-inputs p)) is enough; if (package-inputs p) is
null?, then that’ll return the empty list too.

> +      (native-inputs
> +        (let ((native-inputs (package-native-inputs p)))
> +          (if (null? native-inputs)
> +              '()
> +              (map rewrite native-inputs)))))))

Ditto.

Thanks for working on this!

Ludo’.

Re: Naming scheme for Python packages

[Andreas Enge]

[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]

Hello,

and thanks for your comments! I am attaching a new patch.

On Sat, Sep 07, 2013 at 02:49:07PM +0200, Ludovic Courtès wrote:
> Still it’s better to keep it, as a generic version.  Then, we can have:
>   (define package-with-python-2
>     (cut package-with-explicit-python <> python-2))
> and then use that as needed.

I modified with two additional parameters, OLD-PREFIX and NEW-PREFIX:
When going to python-2, one rewrites the prefix "python-" to "python2-".
The current patch would allow to go back to Python 3 by calling
  (package-with-explicit-python p python "python2-" "python-").

> Sylistic note: never use ‘car’, ‘cdr’, and co; use ‘match’ instead: it
> leads to code that is both more readable and more robust (info "(guile)
> Pattern Matching").  In that case, you can even use ‘match-lambda’,
> which is equivalent to:
>   (lambda (x)
>     (match x
>       ...))

This is rather surprising for a language based on lists...
But admittedly, the code becomes more readable.

> Second remark: inputs are actually tuples of one of two forms:
>   (name package)
>   (name package output)

Or a third one, (name-of-patch store-path-of-patch), which was already
handled. The current patch should handle all cases.

> (map rewrite (package-inputs p)) is enough; if (package-inputs p) is
> null?, then that’ll return the empty list too.

This is something that I had tested, and strangely, it did not work at the
time I made the test. But the error must have lain somewhere else then.

Andreas


[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 3964 bytes --]

diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index ce89281..3ff4da2 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -28,6 +28,7 @@
   #:use-module (gnu packages patchelf)
   #:use-module (guix packages)
   #:use-module (guix download)
+  #:use-module (guix utils)
   #:use-module (guix build-system gnu)
   #:use-module (guix build-system python)
   #:use-module (guix build-system trivial))
@@ -215,9 +216,7 @@ using Python 2.4 or higher and provides access to the Olson timezone database.")
     (license x11)))
 
 (define-public python2-pytz
-  (package (inherit python-pytz)
-    (name "python2-pytz")
-    (arguments (append (package-arguments python-pytz) `(#:python ,python-2)))))
+  (package-with-python2 python-pytz))
 
 (define-public python-babel
   (package
@@ -247,8 +246,4 @@ etc. ")
     (license bsd-3)))
 
 (define-public python2-babel
-  (package (inherit python-babel)
-    (name "python2-babel")
-    (inputs
-     `(("python2-pytz" ,python2-pytz)))
-    (arguments (append (package-arguments python-babel) `(#:python ,python-2)))))
+  (package-with-python2 python-babel))
diff --git a/guix/build-system/python.scm b/guix/build-system/python.scm
index 7ac93b2..30cf6ec 100644
--- a/guix/build-system/python.scm
+++ b/guix/build-system/python.scm
@@ -25,6 +25,7 @@
   #:use-module (guix build-system)
   #:use-module (guix build-system gnu)
   #:use-module (ice-9 match)
+  #:use-module (srfi srfi-26)
   #:export (python-build
             python-build-system))
 
@@ -41,6 +42,55 @@
   (let ((python (resolve-interface '(gnu packages python))))
     (module-ref python 'python-wrapper)))
 
+(define (default-python2)
+  "Return the default Python 2 package."
+  (let ((python (resolve-interface '(gnu packages python))))
+    (module-ref python 'python-2)))
+
+(define (package-with-explicit-python p python old-prefix new-prefix)
+  "Create a package with the same fields as P, which is assumed to use
+PYTHON-BUILD-SYSTEM, such that it is compiled with PYTHON instead.  The
+inputs are changed recursively accordingly.  If the name of P starts with
+OLD-PREFIX, this is replaced by NEW-PREFIX; otherwise, NEW-PREFIX is
+prepended to the name."
+  (let* ((build-system (package-build-system p))
+         (rewrite-if-package
+          (lambda (content)
+            ;; CONTENT may be a string (e.g., for patches), in which case it
+            ;; is returned, or a package, which is rewritten with the new
+            ;; PYTHON and NEW-PREFIX.
+            (if (package? content)
+                (package-with-explicit-python content python
+                                              old-prefix new-prefix)
+                content)))
+         (rewrite
+           (match-lambda
+             ((name content . rest)
+              (append (list name (rewrite-if-package content)) rest)))))
+    (package (inherit p)
+      (name
+        (let ((name (package-name p)))
+          (if (eq? build-system python-build-system)
+              (string-append new-prefix
+                             (if (string-prefix? old-prefix name)
+                                 (substring name (string-length old-prefix))
+                                 name))
+              name)))
+      (arguments
+        (let ((arguments (package-arguments p)))
+          (if (eq? build-system python-build-system)
+              (if (member #:python arguments)
+                  (substitute-keyword-arguments arguments ((#:python p) python))
+                  (append arguments `(#:python ,python)))
+              arguments)))
+      (inputs
+        (map rewrite (package-inputs p)))
+      (native-inputs
+        (map rewrite (package-native-inputs p))))))
+
+(define-public package-with-python2
+  (cut package-with-explicit-python <> (default-python2) "python-" "python2-"))
+
 (define* (python-build store name source inputs
                        #:key
                        (python (default-python))

Re: Naming scheme for Python packages

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sat, Sep 07, 2013 at 02:49:07PM +0200, Ludovic Courtès wrote:
>> Still it’s better to keep it, as a generic version.  Then, we can have:
>>   (define package-with-python-2
>>     (cut package-with-explicit-python <> python-2))
>> and then use that as needed.
>
> I modified with two additional parameters, OLD-PREFIX and NEW-PREFIX:
> When going to python-2, one rewrites the prefix "python-" to "python2-".
> The current patch would allow to go back to Python 3 by calling
>   (package-with-explicit-python p python "python2-" "python-").

Right, makes sense.

Alternately, to improve separation of concerns, there could be a
separate ‘package-with-name-prefix’ procedure, such that we would do:

  (define package-with-python-2
     (compose (cut package-with-name-prefix <> "python2-")
              (cut package-with-explicit-python <> python-2)))

WDYT?

>> Second remark: inputs are actually tuples of one of two forms:
>>   (name package)
>>   (name package output)
>
> Or a third one, (name-of-patch store-path-of-patch), which was already
> handled. The current patch should handle all cases.

Yes.

> +(define (package-with-explicit-python p python old-prefix new-prefix)
> +  "Create a package with the same fields as P, which is assumed to use
> +PYTHON-BUILD-SYSTEM, such that it is compiled with PYTHON instead.  The
> +inputs are changed recursively accordingly.  If the name of P starts with
> +OLD-PREFIX, this is replaced by NEW-PREFIX; otherwise, NEW-PREFIX is
> +prepended to the name."
> +  (let* ((build-system (package-build-system p))
> +         (rewrite-if-package
> +          (lambda (content)
> +            ;; CONTENT may be a string (e.g., for patches), in which case it
> +            ;; is returned, or a package, which is rewritten with the new
> +            ;; PYTHON and NEW-PREFIX.
> +            (if (package? content)
> +                (package-with-explicit-python content python
> +                                              old-prefix new-prefix)
> +                content)))
> +         (rewrite
> +           (match-lambda
> +             ((name content . rest)
> +              (append (list name (rewrite-if-package content)) rest)))))

Instead of having ‘rewrite-if-package’, this can be written like this:

  (define rewrite
    (match-lambda
      ((name (? package p) rest ...)
       ...)
      (x    ; something not a package: leave it as is
       x)))

(I would use an internal ‘define’ like this, rather than ‘let’, to
introduce the ‘rewrite’ procedure; that doesn’t change the semantics,
but I find it easier to read.)

Thanks,
Ludo’.

Re: Naming scheme for Python packages

[Andreas Enge]

On Sun, Sep 08, 2013 at 04:03:23PM +0200, Ludovic Courtès wrote:
> Andreas Enge <andreas@enge.fr> skribis:
> separate ‘package-with-name-prefix’ procedure, such that we would do:
>   (define package-with-python-2
>      (compose (cut package-with-name-prefix <> "python2-")
>               (cut package-with-explicit-python <> python-2)))
> WDYT?

I think one function is enough; there is not much benefit in striving
for maximal generality here, since these two operations should always
be linked in our context.

> (I would use an internal ‘define’ like this, rather than ‘let’, to
> introduce the ‘rewrite’ procedure; that doesn’t change the semantics,
> but I find it easier to read.)

Ah, but that is less functional, no? ;-)

Thanks for the other suggestions, which look quite interesting. The current
solution looks easier to a Scheme neophyte like me, and as there is no major
objection, I am going to push the patch as it is.

This will allow us to go forward with the other problems in the python build
system, and hopefully package a few more modules!

Andreas

Re: Naming scheme for Python packages

[Ludovic Courtès]

Andreas Enge <andreas@enge.fr> skribis:

> On Sun, Sep 08, 2013 at 04:03:23PM +0200, Ludovic Courtès wrote:
>> Andreas Enge <andreas@enge.fr> skribis:
>> separate ‘package-with-name-prefix’ procedure, such that we would do:
>>   (define package-with-python-2
>>      (compose (cut package-with-name-prefix <> "python2-")
>>               (cut package-with-explicit-python <> python-2)))
>> WDYT?
>
> I think one function is enough; there is not much benefit in striving
> for maximal generality here, since these two operations should always
> be linked in our context.

Yeah, right.

>> (I would use an internal ‘define’ like this, rather than ‘let’, to
>> introduce the ‘rewrite’ procedure; that doesn’t change the semantics,
>> but I find it easier to read.)
>
> Ah, but that is less functional, no? ;-)

No; internal ‘define’ is just syntactic sugar equivalent to ‘letrec*’.

> Thanks for the other suggestions, which look quite interesting. The current
> solution looks easier to a Scheme neophyte like me, and as there is no major
> objection, I am going to push the patch as it is.
>
> This will allow us to go forward with the other problems in the python build
> system, and hopefully package a few more modules!

Excellent, thanks!

Ludo’.