Re: Python: inputs vs. propagated inputs
Hi, Ricardo Wurmus skribis: > Hartmut Goebel 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’.
Re: Python: inputs vs. propagated inputs
Hartmut Goebel 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
Python: inputs vs. propagated inputs
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.goe...@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |
