GNU bug report logs - #22013
python2 versions of packages failing as inputs

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22013 in the body.
You can then email your comments to 22013 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: <bug-guix <at> gnu.org>
Subject: python2 versions of packages failing as inputs
Date: Wed, 25 Nov 2015 20:55:17 +0200

[Message part 1 (text/plain, inline)]

Guix build python2-cryptography builds fine, guix build python2-oauthlib
rebuilds python2-cryptography, and fails to build. Python2-cryptography has
an additional input of python2-ipaddress which doesn't get carried along when
python2-cryptography is an input and not the final build.

My guess is that package-with-python2 needs some tweaking. It looks like
python-oauthlib uses python-cryptography, python2-oauthlib uses
(package-with-python2 python-cryptography) instead of python2-cryptography.

I've enclosed `guix graph python2-cryptography python2-oauthlib` as a
visualization of the bug.

-- 
Efraim Flashner   <efraim <at> 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

[graph2 (application/octet-stream, attachment)]

[graph2.pdf (application/pdf, attachment)]

[Message part 4 (application/pgp-signature, inline)]

Message #8 received at 22013 <at> debbugs.gnu.org (full text, mbox):

From: Ricardo Wurmus <rekado <at> elephly.net>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 22013 <at> debbugs.gnu.org
Subject: Re: bug#22013: python2 versions of packages failing as inputs
Date: Wed, 25 Nov 2015 23:00:28 +0100

Efraim Flashner <efraim <at> flashner.co.il> writes:

> Guix build python2-cryptography builds fine, guix build python2-oauthlib
> rebuilds python2-cryptography, and fails to build. Python2-cryptography has
> an additional input of python2-ipaddress which doesn't get carried along when
> python2-cryptography is an input and not the final build.

I think that’s pretty normal.  We have the same situation in
‘python2-openssl’ where we have to explicitly add ‘python2-cryptography’
and remove ‘python-cryptography’.  This is also why any python2 variant
of a package with ‘python-numpy’ among its inputs has to be treated
specially.

It would, of course, be nice if package-with-python2 could handle this
automatically.

~~ Ricardo

Message #11 received at 22013 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 22013 <at> debbugs.gnu.org, Efraim Flashner <efraim <at> flashner.co.il>
Subject: Re: bug#22013: python2 versions of packages failing as inputs
Date: Thu, 26 Nov 2015 09:59:12 +0100

Ricardo Wurmus <rekado <at> elephly.net> skribis:

> Efraim Flashner <efraim <at> flashner.co.il> writes:
>
>> Guix build python2-cryptography builds fine, guix build python2-oauthlib
>> rebuilds python2-cryptography, and fails to build. Python2-cryptography has
>> an additional input of python2-ipaddress which doesn't get carried along when
>> python2-cryptography is an input and not the final build.
>
> I think that’s pretty normal.  We have the same situation in
> ‘python2-openssl’ where we have to explicitly add ‘python2-cryptography’
> and remove ‘python-cryptography’.

Yes, and this is due to the fact that ‘python2-cryptography’ is not just
an automatically-translated package:

  (define-public python2-cryptography
    (let ((crypto (package-with-python2 python-cryptography)))
      (package (inherit crypto)
        (propagated-inputs
         `(("python2-ipaddress" ,python2-ipaddress)
           ,@(package-propagated-inputs crypto))))))

If it were simply equal to (package-with-python2 python-cryptography),
there would be no need for the manual tweak in ‘python-pyopenssl’.

Efraim, could you apply the same strategy as for ‘python2-pyopenssl’ in
‘python2-oauthlib’?

> It would, of course, be nice if package-with-python2 could handle this
> automatically.

I think we would need a way to register “translation” results.
Currently ‘package-with-python2’ internally uses a hash table to memoize
conversion results.  We could imagine adding something like:

  (register-python2-variant PY3VARIANT PY2VARIANT)

to explicitly add a pair to that hash table.

The downside of this approach is that this would break referential
transparency.

WDYT?

Thanks,
Ludo’.

Message #14 received at 22013 <at> debbugs.gnu.org (full text, mbox):

From: Efraim Flashner <efraim <at> flashner.co.il>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 22013 <at> debbugs.gnu.org
Subject: Re: bug#22013: python2 versions of packages failing as inputs
Date: Thu, 26 Nov 2015 12:06:01 +0200

[Message part 1 (text/plain, inline)]

On Thu, 26 Nov 2015 09:59:12 +0100
ludo <at> gnu.org (Ludovic Courtès) wrote:

> Ricardo Wurmus <rekado <at> elephly.net> skribis:
> 
> > Efraim Flashner <efraim <at> flashner.co.il> writes:
> >  
> >> Guix build python2-cryptography builds fine, guix build python2-oauthlib
> >> rebuilds python2-cryptography, and fails to build. Python2-cryptography has
> >> an additional input of python2-ipaddress which doesn't get carried along when
> >> python2-cryptography is an input and not the final build.  
> >
> > I think that’s pretty normal.  We have the same situation in
> > ‘python2-openssl’ where we have to explicitly add ‘python2-cryptography’
> > and remove ‘python-cryptography’.  
> 
> Yes, and this is due to the fact that ‘python2-cryptography’ is not just
> an automatically-translated package:
> 
>   (define-public python2-cryptography
>     (let ((crypto (package-with-python2 python-cryptography)))
>       (package (inherit crypto)
>         (propagated-inputs
>          `(("python2-ipaddress" ,python2-ipaddress)
>            ,@(package-propagated-inputs crypto))))))
> 
> If it were simply equal to (package-with-python2 python-cryptography),
> there would be no need for the manual tweak in ‘python-pyopenssl’.
> 
> Efraim, could you apply the same strategy as for ‘python2-pyopenssl’ in
> ‘python2-oauthlib’?

Ok, I understand now. I thought I had to edit python2-cryptography to fix
python2-oauthlib, now I realize everytime I use python2-cryptography I need
to make sure it pulls the right one.

> 
> > It would, of course, be nice if package-with-python2 could handle this
> > automatically.  
> 
> I think we would need a way to register “translation” results.
> Currently ‘package-with-python2’ internally uses a hash table to memoize
> conversion results.  We could imagine adding something like:
> 
>   (register-python2-variant PY3VARIANT PY2VARIANT)
> 
> to explicitly add a pair to that hash table.
> 
> The downside of this approach is that this would break referential
> transparency.
> 
> WDYT?
> 
> Thanks,
> Ludo’.

We already have the python- and python2- variants as the same packages, just
with the occasional additional input to make it build. Mapping the two
together might speed up package-with-python2.

I'm going to keep on looking at guix/build-systems/python.scm to see if I can
come up with something to not need to specifically declare python2-foo every
time python-foo ends up being used.

-- 
Efraim Flashner   <efraim <at> 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

[Message part 2 (application/pgp-signature, inline)]

Message #19 received at 22013-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Ricardo Wurmus <rekado <at> elephly.net>, 22013-done <at> debbugs.gnu.org
Subject: Re: bug#22013: python2 versions of packages failing as inputs
Date: Sun, 13 Dec 2015 19:16:15 +0100

Efraim Flashner <efraim <at> flashner.co.il> skribis:

> On Thu, 26 Nov 2015 09:59:12 +0100
> ludo <at> gnu.org (Ludovic Courtès) wrote:
>
>> Ricardo Wurmus <rekado <at> elephly.net> skribis:
>> 
>> > Efraim Flashner <efraim <at> flashner.co.il> writes:
>> >  
>> >> Guix build python2-cryptography builds fine, guix build python2-oauthlib
>> >> rebuilds python2-cryptography, and fails to build. Python2-cryptography has
>> >> an additional input of python2-ipaddress which doesn't get carried along when
>> >> python2-cryptography is an input and not the final build.  
>> >
>> > I think that’s pretty normal.  We have the same situation in
>> > ‘python2-openssl’ where we have to explicitly add ‘python2-cryptography’
>> > and remove ‘python-cryptography’.  
>> 
>> Yes, and this is due to the fact that ‘python2-cryptography’ is not just
>> an automatically-translated package:
>> 
>>   (define-public python2-cryptography
>>     (let ((crypto (package-with-python2 python-cryptography)))
>>       (package (inherit crypto)
>>         (propagated-inputs
>>          `(("python2-ipaddress" ,python2-ipaddress)
>>            ,@(package-propagated-inputs crypto))))))
>> 
>> If it were simply equal to (package-with-python2 python-cryptography),
>> there would be no need for the manual tweak in ‘python-pyopenssl’.
>> 
>> Efraim, could you apply the same strategy as for ‘python2-pyopenssl’ in
>> ‘python2-oauthlib’?
>
> Ok, I understand now. I thought I had to edit python2-cryptography to fix
> python2-oauthlib, now I realize everytime I use python2-cryptography I need
> to make sure it pulls the right one.

AFAICS this was fixed in 0066de6, so I’m closing it.

>> > It would, of course, be nice if package-with-python2 could handle this
>> > automatically.  
>> 
>> I think we would need a way to register “translation” results.
>> Currently ‘package-with-python2’ internally uses a hash table to memoize
>> conversion results.  We could imagine adding something like:
>> 
>>   (register-python2-variant PY3VARIANT PY2VARIANT)
>> 
>> to explicitly add a pair to that hash table.
>> 
>> The downside of this approach is that this would break referential
>> transparency.
>> 
>> WDYT?

For this more general issue, we should open a different bug.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.