unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Efraim Flashner <efraim@flashner.co.il>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guix-devel <guix-devel@gnu.org>, 22437@debbugs.gnu.org
Subject: Re: bug#22437: Fixing package-with-python2
Date: Sun, 7 Feb 2016 10:17:20 +0200	[thread overview]
Message-ID: <20160207101720.4a3be103@debian-netbook> (raw)
In-Reply-To: <87twlqxjsc.fsf@gnu.org>

[-- 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 --]

  reply	other threads:[~2016-02-07  8:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01 13:49 Fixing package-with-python2 (was: Package transformations) Thompson, David
2016-02-01 14:26 ` Pjotr Prins
2016-02-01 16:35 ` Efraim Flashner
2016-02-01 16:49   ` Thompson, David
2016-02-01 17:12 ` Andreas Enge
2016-02-01 22:11   ` Fixing package-with-python2 Ludovic Courtès
2016-02-01 22:07 ` Ludovic Courtès
2016-02-01 22:12   ` Thompson, David
2016-02-02  7:50   ` Efraim Flashner
2016-02-03  8:47   ` Ludovic Courtès
2016-02-07  8:17     ` Efraim Flashner [this message]
2016-02-07  9:32       ` bug#22437: " Ricardo Wurmus
2016-02-07 20:35         ` Ludovic Courtès
2016-02-07 20:42       ` Ludovic Courtès
2016-02-08 15:11       ` Ludovic Courtès
2016-02-07 11:09     ` Andreas Enge
2016-02-07 20:39       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160207101720.4a3be103@debian-netbook \
    --to=efraim@flashner.co.il \
    --cc=22437@debbugs.gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).