unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Python: inputs vs. propagated inputs
@ 2016-09-18 18:53 Hartmut Goebel
  2016-09-19  7:45 ` Ricardo Wurmus
  0 siblings, 1 reply; 3+ messages in thread
From: Hartmut Goebel @ 2016-09-18 18:53 UTC (permalink / raw)
  To: Guix-devel

[-- Attachment #1: Type: text/plain, Size: 2290 bytes --]

Hi,

I still do not get whether python packages required at run-time need to
be inputs or propagated inputs.

The part about inputs, native-inputs and propagated-inputs in section
"package Reference" explicitly states Python as an example where
propagated-inputs are needed. Neither the section about the
python-build-system nor the python packaging guidelines give any other
hints.

In gnu/packages/python.scm there are modules using only inputs (e.g.
python-ccm), some are using propagated-inputs (e.g.
python-scikit-image), some using both (e.g. python-paramiko). I can not
see any clear rule being followed.

Also I see a lot of packages defining python-node, python-mock or
python-pytest as inputs (e.g. python-mathplotlib). But these package are
for tests only and tests AFAIK are never run when cross-compiling. Thus
these packages ASAIK are never needed as inputs, only as native-inputs.

I'd like to understand when to put a package where and have a clear rule
like this:

    For Python modules
    - Every Python-package required at run-time need to go into
    propagated inputs.
    - Python packages required only for building or testing go into
    native-inputs. Examples are setuptools, pytest, mock, and nose. Of
    course if one of these packages is required at run-time, it needs to
    be set in propagated-inputs.
    - "inputs" only contain programs or C-libraries (and such) required
    for building python packages containing c-extensions (or such).
    - If a Python package has optional extra dependencies
    (extras_require), not these are not listed here at all - except if
    there is a test-case in which case they are added to native-inputs.
    - If a packages has complicated optional extra dependencies you may
    want to define another package to ease resolving these dependencies
    for the user. E.g. python-projectaaa-ssh inherits python-projectaaa
    and adds the dependencies required for the "ssh" extra feature.

Please comment on these rules. If we agree on a ruleset, I'll prepare a
path for the documentation.

-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |


[-- Attachment #2: Type: text/html, Size: 2926 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Python: inputs vs. propagated inputs
  2016-09-18 18:53 Python: inputs vs. propagated inputs Hartmut Goebel
@ 2016-09-19  7:45 ` Ricardo Wurmus
  2016-10-03 16:13   ` Ludovic Courtès
  0 siblings, 1 reply; 3+ messages in thread
From: Ricardo Wurmus @ 2016-09-19  7:45 UTC (permalink / raw)
  To: Hartmut Goebel; +Cc: Guix-devel


Hartmut Goebel <h.goebel@crazy-compilers.com> writes:

> Hi,
>
> I still do not get whether python packages required at run-time need to
> be inputs or propagated inputs.
>
> The part about inputs, native-inputs and propagated-inputs in section
> "package Reference" explicitly states Python as an example where
> propagated-inputs are needed. Neither the section about the
> python-build-system nor the python packaging guidelines give any other
> hints.
>
> In gnu/packages/python.scm there are modules using only inputs (e.g.
> python-ccm), some are using propagated-inputs (e.g.
> python-scikit-image), some using both (e.g. python-paramiko). I can not
> see any clear rule being followed.

I’d say “python-ccm” is wrong (not only in using “inputs” but also in
its description).

The exception are Python *applications*.  Those usually have a wrapper
to set the PYTHONPATH appropriately.  For Python modules we need
propagated-inputs for everything that must be available at runtime.

~~ Ricardo

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Python: inputs vs. propagated inputs
  2016-09-19  7:45 ` Ricardo Wurmus
@ 2016-10-03 16:13   ` Ludovic Courtès
  0 siblings, 0 replies; 3+ messages in thread
From: Ludovic Courtès @ 2016-10-03 16:13 UTC (permalink / raw)
  To: Ricardo Wurmus; +Cc: Guix-devel

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Hartmut Goebel <h.goebel@crazy-compilers.com> writes:
>
>> Hi,
>>
>> I still do not get whether python packages required at run-time need to
>> be inputs or propagated inputs.
>>
>> The part about inputs, native-inputs and propagated-inputs in section
>> "package Reference" explicitly states Python as an example where
>> propagated-inputs are needed. Neither the section about the
>> python-build-system nor the python packaging guidelines give any other
>> hints.
>>
>> In gnu/packages/python.scm there are modules using only inputs (e.g.
>> python-ccm), some are using propagated-inputs (e.g.
>> python-scikit-image), some using both (e.g. python-paramiko). I can not
>> see any clear rule being followed.
>
> I’d say “python-ccm” is wrong (not only in using “inputs” but also in
> its description).
>
> The exception are Python *applications*.  Those usually have a wrapper
> to set the PYTHONPATH appropriately.  For Python modules we need
> propagated-inputs for everything that must be available at runtime.

I concur.

Hartmut: if you have ideas on how to clarify this in the manual, that
would be welcome!  Probably under “Python Modules”?

Thanks,
Ludo’.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2016-10-03 16:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-18 18:53 Python: inputs vs. propagated inputs Hartmut Goebel
2016-09-19  7:45 ` Ricardo Wurmus
2016-10-03 16:13   ` Ludovic Courtès

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).