[bug#55060,5/6] gnu: Add python-scooby.
Commit Message
* gnu/packages/python-xyz.scm (python-scooby): New variable.
---
gnu/packages/python-xyz.scm | 47 +++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
--
2.35.1
Comments
Paul A. Patience schreef op vr 22-04-2022 om 01:03 [+0000]:
> +
> +(define-public python-scooby
> + (package
> + (name "python-scooby")
The 'python-' prefix is only for library-only python packages. As it
is a called tool, I assume there is some bin/scooby binary that the
user would run?
Greetings,
Maxime.
Paul A. Patience schreef op vr 22-04-2022 om 01:03 [+0000]:
> + (native-inputs
> + (list python-beautifulsoup4
> + python-numpy
> + python-pytest
> + python-pytest-cov
> + python-scipy))
> [no 'inputs' or 'propagated-inputs']
Are these sufficient? According to
<https://github.com/banesullivan/scooby/blob/main/requirements.txt>,
there is also a dependency on 'psutil' and 'mkl'. I have also found
references to those in non-test code.
Greetings,
Maxime.
Paul A. Patience schreef op vr 22-04-2022 om 01:03 [+0000]:
> + (("with pytest\\.raises\\(OSError\\):")
> + "with pytest.raises(ModuleNotFoundError):"))))
What is this for?
Greetings,
Maxime.
Hello Maxime,
I will reply to all of your comments below.
On 2022-04-22 13:53:46-04:00, Maxime Devos wrote:
> The 'python-' prefix is only for library-only python packages. As it
> is a called tool, I assume there is some bin/scooby binary that the
> user would run?
It may be called a tool, but it is only a library, meant to be used from
other libraries.
The readme describes the basic usage as follows:
import scooby
scooby.Report()
On 2022-04-22 13:55:59-04:00, Maxime Devos wrote:
> Paul A. Patience schreef op vr 22-04-2022 om 01:03 [+0000]:
>> + (native-inputs
>> + (list python-beautifulsoup4
>> + python-numpy
>> + python-pytest
>> + python-pytest-cov
>> + python-scipy))
>> [no 'inputs' or 'propagated-inputs']
>
> Are these sufficient? According to
> <https://github.com/banesullivan/scooby/blob/main/requirements.txt>,
> there is also a dependency on 'psutil' and 'mkl'. I have also found
> references to those in non-test code.
The setup.py file lists psutil and mkl in extras_require, meaning they
are optional.
mkl (https://pypi.org/project/mkl/) is released under the Intel
Simplified Software License, which I suspect is ideologically
incompatible with Guix (and therefore not already packaged for Guix), so
I didn't include it.
I omitted psutil just because I was omitting mkl, but I can add it as a
propagated input.
On 2022-04-22 14:07:43-04:00, Maxime Devos wrote:
> Paul A. Patience schreef op vr 22-04-2022 om 01:03 [+0000]:
>> + (("with pytest\\.raises\\(OSError\\):")
>> + "with pytest.raises(ModuleNotFoundError):"))))
>
> What is this for?
It seems the test suite expects the import of a missing package to throw
an OSError instead of a ModuleNotFoundError, which is not the case at
least on Python 3.9.9.
I don't know if it was different before.
I can add a comment to that effect.
On 2022-04-22 13:51:26-04:00, Maxime Devos wrote:
> Paul A. Patience schreef op vr 22-04-2022 om 12:41 [+0000]:
>> + (synopsis "Great Dane turned Python environment detective")
>
> What does this package have to do with Denmark and detectives?
>
> Looking further, ‘Great Dane’ appears to be some dog breed, and I guess
> it's a pun on the package name and Scooby-Doo. However, I don't think
> this is useful for users looking for packages that suit their needs.
>
>> + (description
>> + "This is a lightweight tool for easily reporting your Python
>> +environment's package versions and hardware resources.")
>
> Isn't this just ‘guix package --list-installed=^python’?
> What hardware resources does it report? CPU models? Disk
> manufacturers? The attached peripherals? Non-physical peripherals
> like e.g. bluetooth mice? The amount of ductape holding the computer
> together? Information about the printer? ...
>
> ALso, lightweight and easy is rather subjective. Compares to lscpu,
> lspci, ..., (which are simple C tools IIUC) depending on python and
> python-scipy doesn't seem lightweight to me. ‘(guix)Synopses and
> Descriptions’ recommends staying factual.
The synopsis and description are taken wholesale from Scooby's readme.
However, I can rewrite them.
Best regards,
Paul
Paul A. Patience schreef op vr 22-04-2022 om 19:26 [+0000]:
> It seems the test suite expects the import of a missing package to throw
> an OSError instead of a ModuleNotFoundError, which is not the case at
> least on Python 3.9.9.
> I don't know if it was different before.
> I can add a comment to that effect.
This version incompatibility seems like something upstream needs to
know about. I've commented upstream at
<https://github.com/banesullivan/scooby/pull/74>.
Greetings,
Maxime.
Paul A. Patience schreef op vr 22-04-2022 om 19:26 [+0000]:
> The setup.py file lists psutil and mkl in extras_require, meaning they
> are optional.
The manual has the following to say about optional dependencies:
• If a Python package has optional dependencies (‘extras_require’),
it is up to you to decide whether to add them or not, based on
their usefulness/overhead ratio (*note ‘guix size’: Submitting
Patches.).
I don't know if this changes anything here.
> mkl (https://pypi.org/project/mkl/) is released under the Intel
> Simplified Software License, which I suspect is ideologically
> incompatible with Guix (and therefore not already packaged for Guix), so
> I didn't include it.
Ok -- the pypi.org page even says ‘proprietary license’!
Greetings,
Maxime.
Paul A. Patience schreef op vr 22-04-2022 om 19:26 [+0000]:
> It seems the test suite expects the import of a missing package to throw
> an OSError instead of a ModuleNotFoundError, which is not the case at
> least on Python 3.9.9.
> I don't know if it was different before.
> I can add a comment to that effect.
Upstream says we need to add 'pyvips' as listed in
test_requirements.txt.
Greetings,
MAxime.
On 2022-04-29 16:52:26-04:00, Maxime Devos wrote:
> Upstream says we need to add 'pyvips' as listed in
> test_requirements.txt.
How would I add a python-pyvips native input that doesn't actually
depend on the vips package?
From my understanding of banesullivan's explanation [1], the test checks
for the presence of pyvips in the absence of vips.
I suppose a python-pyvips-for-python-scooby that inherits from
python-pyvips while removing its propagated inputs would do.
Best regards,
Paul
[1]: https://github.com/banesullivan/scooby/pull/74#issuecomment-1113703071
Paul A. Patience schreef op ma 02-05-2022 om 15:00 [+0000]:
> I suppose a python-pyvips-for-python-scooby that inherits from
> python-pyvips while removing its propagated inputs would do.
AFAICT, python-pyvips does not currently exist, at least according to
"guix show python-pyvips". That said, maybe it could be depropagated
(maybe there's no need for a package variant)?
Greetings,
Maxime.
On 2022-05-02 11:06:52-04:00, Maxime Devos wrote:
> Paul A. Patience schreef op ma 02-05-2022 om 15:00 [+0000]:
>> I suppose a python-pyvips-for-python-scooby that inherits from
>> python-pyvips while removing its propagated inputs would do.
>
> AFAICT, python-pyvips does not currently exist, at least according to
> "guix show python-pyvips".
I would have to package it (I'm currently doing so).
> That said, maybe it could be depropagated
> (maybe there's no need for a package variant)?
Do you mean with a package transformation directly in python-scooby's
native inputs?
Best regards,
Paul
Paul A. Patience schreef op ma 02-05-2022 om 15:33 [+0000]:
> > That said, maybe it could be depropagated
> > (maybe there's no need for a package variant)?
>
> Do you mean with a package transformation directly in python-scooby's
> native inputs?
No, I mean modifying the python-pyvips package definition to move
'vips' from 'propagated-inputs' to 'inputs' (as-is, this might cause
problems as 'python-pyvips' might then not find 'vips', but such things
can often be resolved by sufficient application of 'substitute*').
Greetings,
Maxime.
@@ -29534,3 +29534,50 @@ (define-public python-sre-yield
uses the parsed regular expression, so you get a much more accurate result
than trying to just split strings.")
(license license:asl2.0)))
+
+(define-public python-scooby
+ (package
+ (name "python-scooby")
+ (version "0.5.12")
+ (source
+ ;; The PyPI tarball does not contain the tests.
+ (origin
+ (method git-fetch)
+ (uri (git-reference
+ (url "https://github.com/banesullivan/scooby")
+ (commit (string-append "v" version))))
+ (file-name (git-file-name name version))
+ (sha256
+ (base32 "1gkpmz8wl3jg8ylf1na35308sznw2g9wx33zqlyq5i2gpy2ml9mw"))))
+ (build-system python-build-system)
+ (native-inputs
+ (list python-beautifulsoup4
+ python-numpy
+ python-pytest
+ python-pytest-cov
+ python-scipy))
+ (arguments
+ `(#:phases
+ (modify-phases %standard-phases
+ (add-after 'unpack 'fix-tests
+ (lambda _
+ (substitute* "tests/test_scooby.py"
+ ;; The test suite uses the no-version PyPI package
+ ;; (https://pypi.org/project/no-version/),
+ ;; but it doesn't seem worth packaging in Guix just for this.
+ (("scooby\\.report\\.VERSION_NOT_FOUND")
+ "scooby.report.MODULE_NOT_FOUND")
+ (("^ +import no_version # noqa.*") "")
+ (("with pytest\\.raises\\(OSError\\):")
+ "with pytest.raises(ModuleNotFoundError):"))))
+ (replace 'check
+ (lambda* (#:key tests? inputs outputs #:allow-other-keys)
+ (when tests?
+ (add-installed-pythonpath inputs outputs)
+ (invoke "pytest")))))))
+ (home-page "https://github.com/banesullivan/scooby")
+ (synopsis "Great Dane turned Python environment detective")
+ (description
+ "This is a lightweight tool for easily reporting your Python
+environment's package versions and hardware resources.")
+ (license license:expat)))