[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Python and propagated inputs
From: |
Ludovic Courtès |
Subject: |
Python and propagated inputs |
Date: |
Tue, 28 Jun 2016 14:28:45 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
address@hidden (宋文武) skribis:
>>> They're needed at runtime, and included in the pth file.
>>> But I'm not sure whether or not inputs for python should be
>>> native-inputs, I never cross build python modules for other
>>> architertures.
>>
>> If they’re used at run time, they’re not ‘native-inputs’. (In practice
>> we cannot cross-compile Python stuff currently, so this is largely a
>> theoretical concern, but it doesn’t cost much to get it right.)
>>
>>> Should I put dnspython and idna into inputs, or propagated-inputs?
>>
>> If the installed code “import”s them, then they should be propagated.
> OK, done. I'm fine with propagated them, but there are many python
> packages use inputs for runtime depends and rely on the pth file too.
>
> What's the current practice?
>
>
> Also, last dicussed at:
> <https://lists.gnu.org/archive/html/guix-devel/2016-04/msg01020.html>
AIUI, what Ricardo is saying in this message is that current practice is
to propagate inputs that are needed at run time, even though that sucks
in some ways.
Ludo’.
[PATCH 09/10] gnu: Add python-ukpostcodeparser and python2-ukpostcodeparser., 宋文武, 2016/06/23
[PATCH 10/10] gnu: Add python-fake-factory and python2-fake-factory., 宋文武, 2016/06/23
Re: [PATCH 05/10] gnu: Add python-cleo and python2-cleo., Leo Famulari, 2016/06/25