unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
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’.

  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).