diff mbox series

[bug#42390] gnu: Add python-mamba.

Message ID 20200716122530.29231-1-tanguy@bioneland.org
State Accepted
Headers show
Series [bug#42390] gnu: Add python-mamba. | expand

Checks

Context Check Description
cbaines/applying patch fail View Laminar job

Commit Message

Tanguy LE CARROUR July 16, 2020, 12:25 p.m. UTC
* gnu/packages/python-xyz.scm (python-mamba): New variable.
---
 gnu/packages/python-xyz.scm | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

Comments

Ludovic Courtès July 21, 2020, 4:41 p.m. UTC | #1
Hi,

Tanguy Le Carrour <tanguy@bioneland.org> skribis:

> * gnu/packages/python-xyz.scm (python-mamba): New variable.

Applied, thanks!

There’s a lint warning though I don’t know if it’s applicable:

--8<---------------cut here---------------start------------->8---
gnu/packages/python-xyz.scm:14542:2: python-mamba@0.11.0: 'python-coverage' should probably be a native input
--8<---------------cut here---------------end--------------->8---

If ‘python-coverage’ is only used at build time, then it should
definitely be a native input.

WDYT?

Ludo’.
Tanguy LE CARROUR July 22, 2020, 7:36 a.m. UTC | #2
Hi,

Le 07/21, Ludovic Courtès a écrit :
> Tanguy Le Carrour <tanguy@bioneland.org> skribis:
> > * gnu/packages/python-xyz.scm (python-mamba): New variable.
> […]
> 
> There’s a lint warning though I don’t know if it’s applicable:
> 
> --8<---------------cut here---------------start------------->8---
> gnu/packages/python-xyz.scm:14542:2: python-mamba@0.11.0: 'python-coverage' should probably be a native input
> --8<---------------cut here---------------end--------------->8---
> 
> If ‘python-coverage’ is only used at build time, then it should
> definitely be a native input.
> 
> WDYT?

I saw the warning (should I have mentioned it in the bug report?),
but `python-coverage` is definitively a run time dependency.
If I remove it, I get:

```
pkg_resources.DistributionNotFound: The 'coverage' distribution was not found and is required by mamba
```

Is there a way to know why the linter is reporting it?!

FYI, I might update `python-mamba` in a near future to fetch the sources from git
and enable the check phase. But this requires that I add (at least) 2 more
packages. So this will have to wait for the week-end.

Regards
Ludovic Courtès July 22, 2020, 10:38 a.m. UTC | #3
Howdy,

(+Cc: Hartmut.)

Tanguy Le Carrour <tanguy@bioneland.org> skribis:

> Le 07/21, Ludovic Courtès a écrit :
>> Tanguy Le Carrour <tanguy@bioneland.org> skribis:
>> > * gnu/packages/python-xyz.scm (python-mamba): New variable.
>> […]
>> 
>> There’s a lint warning though I don’t know if it’s applicable:
>> 
>> --8<---------------cut here---------------start------------->8---
>> gnu/packages/python-xyz.scm:14542:2: python-mamba@0.11.0: 'python-coverage' should probably be a native input
>> --8<---------------cut here---------------end--------------->8---
>> 
>> If ‘python-coverage’ is only used at build time, then it should
>> definitely be a native input.
>> 
>> WDYT?
>
> I saw the warning (should I have mentioned it in the bug report?),
> but `python-coverage` is definitively a run time dependency.
> If I remove it, I get:
>
> ```
> pkg_resources.DistributionNotFound: The 'coverage' distribution was not found and is required by mamba
> ```

Ah, I see.

> Is there a way to know why the linter is reporting it?!

I don’t know, it comes from commit
e442246a2f5f73b2484adb340b53d3a0018636b1 by Hartmut (Cc’d.)

Hartmut, it looks like there are cases like this where python-coverage
is used as a library and thus should not be in ‘native-inputs’.  Should
we remove it from the list?

Thanks,
Ludo’.
Hartmut Goebel July 23, 2020, 7:19 p.m. UTC | #4
Am 22.07.20 um 12:38 schrieb Ludovic Courtès:
> Hartmut, it looks like there are cases like this where python-coverage
> is used as a library and thus should not be in ‘native-inputs’.  Should
> we remove it from the list?

This depends on whether you see "guix lint" as a helper or an enforcer -
and on how one classifies this package.

IMHO lint is a helper and coverage is used at build-time only most of
the time. This is why I added it to the list. YMMV, though.

In the case of python-mamba - which is a test-runner -,
"propagated-input" seems to be correct, so lint gives inaccurate advice
here.
Tanguy LE CARROUR July 24, 2020, 6:36 a.m. UTC | #5
Le 07/23, Hartmut Goebel a écrit :
> Am 22.07.20 um 12:38 schrieb Ludovic Courtès:
> > Hartmut, it looks like there are cases like this where python-coverage
> > is used as a library and thus should not be in ‘native-inputs’.  Should
> > we remove it from the list?
> 
> This depends on whether you see "guix lint" as a helper or an enforcer -
> and on how one classifies this package.
> 
> IMHO lint is a helper and coverage is used at build-time only most of
> the time. This is why I added it to the list. YMMV, though.
> 
> In the case of python-mamba - which is a test-runner -,
> "propagated-input" seems to be correct, so lint gives inaccurate advice
> here.

Thanks Hartmut! This makes sense.
The only problem is that it adds to the noise. :-(
Wouldn't it be possible to mark such exception in the package definition?
With flake8, I often find myself adding a `noqa` comment, for instance.
I do the same with mypy with `type: ignore`.
Ludovic Courtès July 24, 2020, 1:14 p.m. UTC | #6
Hi,

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

> Am 22.07.20 um 12:38 schrieb Ludovic Courtès:
>> Hartmut, it looks like there are cases like this where python-coverage
>> is used as a library and thus should not be in ‘native-inputs’.  Should
>> we remove it from the list?
>
> This depends on whether you see "guix lint" as a helper or an enforcer -
> and on how one classifies this package.

The message is “python-coverage should probably be a native input”.
That suggests it’s unlikely (but not impossible) to be a false positive.

To me, we should keep python-coverage in the list only if we know it
should be a native input 90% of the time.

Tanguy, Hartmut, do you have an estimate here?  :-)

Adding a package property to instruct ‘guix lint’ to ignore the issue
would also work, as Tanguy proposed.

Ludo’.
Hartmut Goebel July 27, 2020, 7:47 a.m. UTC | #7
Am 24.07.20 um 15:14 schrieb Ludovic Courtès:
> To me, we should keep python-coverage in the list only if we know it
> should be a native input 90% of the time.

> 90%

Rational: Checking code-coverage is a typical part of testing, thus like
other testing-tools, coverage is required native. The only case, this
module is *not* a native input are test-suites/test-runner like
python-mamba.
Tanguy LE CARROUR July 27, 2020, 8:10 a.m. UTC | #8
Le 07/27, Hartmut Goebel a écrit :
> Am 24.07.20 um 15:14 schrieb Ludovic Courtès:
> > To me, we should keep python-coverage in the list only if we know it
> > should be a native input 90% of the time.
> 
> > 90%
> 
> Rational: Checking code-coverage is a typical part of testing, thus like
> other testing-tools, coverage is required native. The only case, this
> module is *not* a native input are test-suites/test-runner like
> python-mamba.

+1!

The question is now: is it possible to make the warning go away by
marking it as being an "exception" in the package definition?
Are comments "part of the code" and be used for that? Can we use a
different package name (`python-coverage-propagated`) that would not
be in the list?
Ludovic Courtès July 28, 2020, 9:56 p.m. UTC | #9
Hi,

Tanguy Le Carrour <tanguy@bioneland.org> skribis:

> The question is now: is it possible to make the warning go away by
> marking it as being an "exception" in the package definition?
> Are comments "part of the code" and be used for that? Can we use a
> different package name (`python-coverage-propagated`) that would not
> be in the list?

We could use a property, similar to how the ‘lint-hidden-cve’ property
is handled by the ‘cve’ linter.

Ludo’.
Tanguy LE CARROUR July 29, 2020, 6:52 a.m. UTC | #10
Hi,

Le 07/28, Ludovic Courtès a écrit :
> Tanguy Le Carrour <tanguy@bioneland.org> skribis:
> 
> > The question is now: is it possible to make the warning go away by
> > marking it as being an "exception" in the package definition?
> > Are comments "part of the code" and be used for that? Can we use a
> > different package name (`python-coverage-propagated`) that would not
> > be in the list?
> 
> We could use a property, similar to how the ‘lint-hidden-cve’ property
> is handled by the ‘cve’ linter.

Sounds great! … unless you expected me to implement it! ^_^'
I guesse `check-inputs-should-be-native` should look a bit like
`check-vulnerabilities`, but I have no idea how to do that! Sorry!
Tanguy LE CARROUR July 31, 2020, 6:42 a.m. UTC | #11
For the record, I also have a lint warning with `python-robber`
(WIP: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=42364), because
it propagates `python-mock`.
diff mbox series

Patch

diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
index 15d9e097c5..b5485caa3a 100644
--- a/gnu/packages/python-xyz.scm
+++ b/gnu/packages/python-xyz.scm
@@ -14394,6 +14394,28 @@  in other versions.")
 (define-public python2-configparser
   (package-with-python2 python-configparser))
 
+(define-public python-mamba
+  (package
+    (name "python-mamba")
+    (version "0.11.0")
+    (source (origin
+              (method url-fetch)
+              (uri (pypi-uri "mamba" version))
+              (sha256
+               (base32
+                "0bpbgz9v63rpanjjpc8bnvrr8fkms5rzylh77xrcki1x6az7gnsz"))))
+    (build-system python-build-system)
+    (arguments `(#:tests? #f))  ; No test
+    (propagated-inputs
+     `(("python-clint" ,python-clint)
+       ("python-coverage" ,python-coverage)))
+    (home-page "https://nestorsalceda.com/mamba/")
+    (synopsis "Test runner for Python")
+    (description
+     "Mamba is a Behaviour-Driven Development tool for Python developers.
+Is heavily influenced from RSpec, Mocha, Jasmine or Ginkgo.")
+    (license license:expat)))
+
 (define-public python-mando
   (package
     (name "python-mando")