| Message ID | 20220422010244.23280-5-paul@apatience.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [bug#55060,1/6] gnu: python-meshio: Remove input labels. | expand |
| Context | Check | Description |
|---|---|---|
| cbaines/comparison | success | View comparision |
| cbaines/git branch | success | View Git branch |
| cbaines/applying patch | success | View Laminar job |
| cbaines/issue | success | View issue |
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.
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm index 9a5d311680..799a6441ea 100644 --- a/gnu/packages/python-xyz.scm +++ b/gnu/packages/python-xyz.scm @@ -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)))