[bug#42082] [PATCH 1/6] gnu: Add python-covdefaults.

[Marius Bakke <marius@gnu.org>]

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

Vinicius Monego <monego@posteo.net> writes:

> Em seg, 2020-07-20 às 23:13 +0200, Marius Bakke escreveu:
>> Hi Vinicius,
>
> Hello Marius,
>
> Thanks for the tips!
>
>> We now have a 'python-check.scm' which is preferable to
>> check.scm.  Can
>> you add this library there instead?
>
> Sure. I overlooked that file. I sent another series of 6 pytest patches
> before this, and will send a v2 for that as well.

Excellent, thank you.

>> Should pytest be propagated here?
>> 
>> Also, as this package is a plugin for coverage, maybe it should not
>> propagate coverage either.  The reason is that propagating prevents
>> it
>> from being (easily) used with other versions of coverage.  Let's say
>> that a package needs a newer coverage than the default in Guix + this
>> plugin, propagation here would bring in the wrong coverage version.
>
> Oh, I thought that the pytest binary should be available as an
> executable for the plugin to be used, similar to how APT has pytest as
> a dependency for plugins. Maybe it's just me thinking in terms of
> traditional package management.
>
> The PyPI importer will propagate pytest by default, and it's common to
> see it propagated in other plugins in check.scm. But now I see that
> many plugins do not propagate it. Should pytest not be an input at all
> (unless the plugin uses it for its own tests, in which case it should
> be a native input)?

There are differing opinions on this matter :-) I would say that pytest
should _not_ be propagated in this case, so that the plugin can be used
with custom versions of pytest.  Others might say that the plugin is
useless without pytest, and so it _should_ be propagated.

I'll leave the final say to you.  :-)

>> I know it's a lot to ask :-) but can you try to expand on how it
>> differs
>> from the apparently unreasonable defaults in coverage?  "Sensible"
>> also
>> borders on "marketing speak", perhaps "opinionated" is a better term.
>
> That's a slight rewording of the author's description in the
> repository, and that's the only verbal information I could find about
> the project. The differences can be seen in the README and in the
> source code, but I don't know what to write about them, or even why the
> changes are 'more sensible'.

Right, not great.  We should at least try and stay neutral (see the
"Synopses and Descriptions" section of the manual).  So
s/sensible/opinionated/ is good enough for me.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]