bug-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22013: python2 versions of packages failing as inputs


From: Ludovic Courtès
Subject: bug#22013: python2 versions of packages failing as inputs
Date: Sun, 13 Dec 2015 19:16:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Efraim Flashner <address@hidden> skribis:

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]