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

* gnu/packages/check.scm (python-covdefaults): New variable.
---
 gnu/packages/check.scm | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

Hi Vinicius,

Sorry for the slow response.  The series look great overall, but I have
a few nitpicks.  :-)

Vinicius Monego <monego@posteo.net> writes:

> * gnu/packages/check.scm (python-covdefaults): New variable.

We now have a 'python-check.scm' which is preferable to check.scm.  Can
you add this library there instead?

Ideally we'd move the current Python test libraries over too, but that's
another issue.

[...]
  
> +(define-public python-covdefaults
> +  (package
> +    (name "python-covdefaults")
> +    (version "1.1.0")
> +    (source
> +     (origin
> +       ;; The PyPI tarball does not include tests.
> +       (method git-fetch)
> +       (uri (git-reference
> +             (url "https://github.com/asottile/covdefaults")
> +             (commit (string-append "v" version))))
> +       (file-name (git-file-name name version))
> +       (sha256
> +        (base32 "11a24c0wzv01n55fy4kdpnyqna4m9k0mp58kmhiaks34xw4k37hq"))))
> +    (build-system python-build-system)
> +    (arguments
> +     `(#:phases
> +       (modify-phases %standard-phases
> +         (replace 'check
> +           (lambda _
> +             (invoke "pytest" "-vv")
> +             #t)))))

Note: invoke returns #t on success, so no need for the explicit return
(though it does not hurt).

> +    (propagated-inputs
> +     `(("python-coverage" ,python-coverage)
> +       ("python-pytest" ,python-pytest)))

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.

> +    (home-page "https://github.com/asottile/covdefaults")
> +    (synopsis "Coverage plugin to provide sensible default settings")
> +    (description
> +     "Covdefaults is a coverage plugin to provide sensible default settings.")

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.

This was more text than I intended for an otherwise good-looking patch!
Will comment on the others too.

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.

> 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)?

> 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'.

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.

merge 42082 42083 42084 42085 42086 42087