--- Begin Message ---
|
Subject: |
python2 versions of packages failing as inputs |
|
Date: |
Wed, 25 Nov 2015 20:55:17 +0200 |
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 <address@hidden> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
graph2
Description: Binary data
graph2.pdf
Description: Adobe PDF document
pgpSdeKki2_dX.pgp
Description: OpenPGP digital signature
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: 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’.
--- End Message ---