bug#22437: Fixing package-with-python2

[Efraim Flashner <efraim@flashner.co.il>]

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

On Wed, 03 Feb 2016 09:47:15 +0100
ludo@gnu.org (Ludovic Courtès) wrote:

> ludo@gnu.org (Ludovic Courtès) skribis:
> 
> > An idea I haven’t taken the time to test yet would be to use
> > ‘properties’:
> >
> >   (define python-foobar   ;with Python 3
> >     (package
> >       (name "foobar")
> >       ;; Specify which Python 2 variant to use.
> >       (properties `((python2-variant . ,(delay python2-foobar))))))

This part I don't get. What's the period for?

> >   (define python2-foobar
> >     (package (inherit python-foobar)
> >       ;; … stuff beyond the mechanical python 2→3 switch…
> >       ))
> >
> > ‘package-with-python2’ would honor this ‘python2-variant’ property.
> 
> Here’s a first stab at this.
> 
> As an example, I modified ‘python-matplotlib’ to use that feature, so we
> can test that ‘python2-scipy’ is using the right ‘python2-matplotlib’:
> 
> --8<---------------cut here---------------start------------->8---
> $ ./pre-inst-env guix build python2-matplotlib -d 2>/dev/null
> /gnu/store/07zr2pqg61b742czb2aqyisml2i90r4a-python2-matplotlib-1.4.3.drv
> $ ./pre-inst-env guix build python2-scipy -d 2>/dev/null
> /gnu/store/8yhxdbyjvx2xwynpqqcrj9ilksd2pb01-python2-scipy-0.16.0.drv
> $ guix gc --references /gnu/store/8yhxdbyjvx2xwynpqqcrj9ilksd2pb01-python2-scipy-0.16.0.drv | grep python2-matplotlib
> /gnu/store/07zr2pqg61b742czb2aqyisml2i90r4a-python2-matplotlib-1.4.3.drv
> --8<---------------cut here---------------end--------------->8---
> 
> This will trigger rebuilds (but with an identical result) because in
> manually-written variants we would use “python2-foo” as the label of
> inputs, whereas the automatic transformations keeps the original
> “python-foo” label.

rebuilds python-foo and python2-foo, or just the python2- variants?

> What do people think?

I like it. It keeps the logic in the build-system. In terms of a speed test
when figuring out the build/dependancy graph, how does it affect the time of
`guix graph python2-scipy python2-matplotlib`?

> I can apply this patch of the approach sounds good to you.  I think we
> should probably do one commit per rewrite for clarity.
> 
> We should probably start with the lowest level, like python2-pycairo and
> python2-pygobject and even python itself, because if we fix them then
> some of the higher-level stuff won’t even need their own
> ‘python2-variant’ property.  For instance, if python, pycairo, and
> pygobject have their ‘python2-variant’ set, then we no longer need this:
> 
> --8<---------------cut here---------------start------------->8---
> (define-public python2-matplotlib
>   (let ((matplotlib (package-with-python2 %python-matplotlib)))
>     (package (inherit matplotlib)
>       ;; Make sure to use special packages for Python 2 instead
>       ;; of those automatically rewritten by package-with-python2.
>       (propagated-inputs
>        `(("python2-pycairo" ,python2-pycairo)
>          ("python2-pygobject-2" ,python2-pygobject-2)
>          ("python2-tkinter" ,python-2 "tk")
>          ,@(fold alist-delete (package-propagated-inputs matplotlib)
>                  '("python-pycairo" "python-pygobject" "python-tkinter")))))))
> --8<---------------cut here---------------end--------------->8---
> 
> … and as a consequence, we don’t need a ‘python2-variant’ in
> ‘python-matplotlib’.
> 
> Does that make sense?  Any takers?  (This can be done incrementally.)

It fits our "one change per commit" policy, and if we don't start at the base
of the pyramid we'll be modifying and then removing the special variants. I
don't mind doing the conversion process.

> Thanks,
> Ludo’.
> 

Thinking aloud, I think for the time being we should keep the
python-setuptools that are already part of the python- variants where they
are and save that for another time.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]