From: ludo@gnu.org (Ludovic Courtès)
To: Efraim Flashner <efraim@flashner.co.il>
Cc: guix-devel <guix-devel@gnu.org>, 22437@debbugs.gnu.org
Subject: bug#22437: Fixing package-with-python2
Date: Sun, 07 Feb 2016 21:42:26 +0100 [thread overview]
Message-ID: <87r3gos159.fsf@gnu.org> (raw)
In-Reply-To: <20160207101720.4a3be103@debian-netbook> (Efraim Flashner's message of "Sun, 7 Feb 2016 10:17:20 +0200")
Efraim Flashner <efraim@flashner.co.il> skribis:
> On Wed, 03 Feb 2016 09:47:15 +0100
> ludo@gnu.org (Ludovic Courtès) wrote:
[...]
>> 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?
The latter.
>> 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`?
It might be slightly faster, but it’s already rather fast. :-)
--8<---------------cut here---------------start------------->8---
$ time guix graph python2-scipy python2-matplotlib >/dev/null
real 0m0.664s
user 0m0.768s
sys 0m0.056s
--8<---------------cut here---------------end--------------->8---
[...]
>> 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.
OK.
> 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.
Agreed.
Thanks for your feedback!
Ludo’.
next prev parent reply other threads:[~2016-02-07 20:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CAJ=RwfZJJ36=bdwyxfN1ov7__KW_8u7LD8ous--9LUcsHEEzmg@mail.gmail.com>
[not found] ` <87vb68nkyb.fsf@gnu.org>
2016-02-03 8:47 ` bug#22437: Fixing package-with-python2 Ludovic Courtès
[not found] ` <87twlqxjsc.fsf@gnu.org>
2016-02-07 8:17 ` Efraim Flashner
[not found] ` <20160207101720.4a3be103@debian-netbook>
2016-02-07 9:32 ` Ricardo Wurmus
[not found] ` <87h9hkx3ur.fsf@elephly.net>
2016-02-07 20:35 ` Ludovic Courtès
2016-02-07 20:42 ` Ludovic Courtès [this message]
2016-02-08 15:11 ` Ludovic Courtès
2016-02-07 11:09 ` Andreas Enge
[not found] ` <20160207110929.GA4968@debian>
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=87r3gos159.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=22437@debbugs.gnu.org \
--cc=efraim@flashner.co.il \
--cc=guix-devel@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).