Re: Python's native-inputs

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Nicolas,

Nicolas Graves via "Development of GNU Guix and the GNU System
distribution." <guix-devel@gnu.org> writes:

> Hi Guix,
>
> On some languages, there are a lot of unused native-inputs that are
> development & linting dependencies much more than packages that are
> actually used to build or test a package (I'm thinking at least Python
> and Rust). These fall in the category of tools "useful" at run time, but
> unecessary at build time.

Indeed.

> Is there a clear policy about their removal? I've seen the case of
> pre-commit in Python, and I've commited a series yesterday regarding
> pylint, but there are a whole lot of them in Python, at least :

[...]

> These packages make a lot of sense when considering things like
> `guix shell -D` but they are hampering some progress on Python packages
> since they are everywhere and a small update in their inputs rebuilds
> the whole python world (even though it has NO influence on the
> functionality of any other package).
>
> What are the guidelines in this case?

There aren't really any guidelines.  It's easy to avoid the linters, it
makes sense to avoid them, but sometimes upstream makes it difficult to
avoid running a linter as part of there test suite, in which case I
think it's acceptable to keep them as native-inputs rather than come up
with more patches to maintain.

> I can propose a huge patch series (currently ~300 patches, and not
> finished), to remove them, lint against them and remove them from the
> importer as a default, but that's a big decision to make. IMO we should
> have a dev-inputs field to handle these cases, but that's even more work.

The situation is similar as for other test inputs such as pytest; it has
an enormous amounts of dependents and thus cannot be easily upgraded on
the master branch.  At least more up-to-date variants can be added since
these are not in the transitive closure of any packages.

I don't think we should go out of our way to address annoyances that
upstream have caused -- that'd be too much work to maintain in the long
run.

-- 
Thanks,
Maxim