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 --]
next prev parent 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).