Subject: bug#22013: closed (Re: bug#22013: python2 versions of packages failing as inputs)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 13 Dec 2015 18:17:02 +0000

Your bug report

#22013: python2 versions of packages failing as inputs

which was filed against the guix package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
22013: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22013
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#22013: python2 versions of packages failing as inputs
From: [email-masked] (Ludovic Courtès)
To: Efraim Flashner <[email-masked]>
Cc: Ricardo Wurmus <[email-masked]>, [email-masked]
Date: Sun, 13 Dec 2015 19:16:15 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

Efraim Flashner <[email-masked]> skribis:

> On Thu, 26 Nov 2015 09:59:12 +0100
> [email-masked] (Ludovic Courtès) wrote:
>
>> Ricardo Wurmus <[email-masked]> skribis:
>> 
>> > Efraim Flashner <[email-masked]> 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’.

Subject: python2 versions of packages failing as inputs
From: Efraim Flashner <[email-masked]>
To: <[email-masked]>
Date: Wed, 25 Nov 2015 20:55:17 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

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   <[email-masked]>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted