mbox series

[bug#68789,0/2] gnu: Add python-pyjanitor.

Message ID 87il3df4y5.fsf@troyfigiel.com
Headers show
Series gnu: Add python-pyjanitor. | expand

Message

Troy Figiel Jan. 28, 2024, 10:49 p.m. UTC 
This patch series adds python-pyjanitor and its dependency python-unyt.

Troy Figiel (2):
  gnu: Add python-unyt.
  gnu: Add python-pyjanitor.

 gnu/packages/python-science.scm | 88 +++++++++++++++++++++++++++++++++
 1 file changed, 88 insertions(+)


base-commit: 08ed3ec64ecd571d92d497b2493f5c0225102c99

Comments

Sharlatan Hellseher Jan. 29, 2024, 2:26 p.m. UTC | #1 
Hi Troy,

Thank you for the patches!

I'm in the process of packaging python-yt in (gnu packages astronomy)
and I've noticed that python-unyt is part of it which brought me here
:-) I started reviewing this issue so.

One note - you introduced a module cycle which was not before
astronomy->python-science->astronomy. If the requirement of
python-astropy is soft let's silent it for now.

Also I've already updated the whole chain depending on python-astropy
after it's update to 6.0.0, letting you know if your work requires fresh
Astropy version. It will be in review on 20th next month.

What do you think?

Regards,
Oleg
Troy Figiel Jan. 29, 2024, 5:18 p.m. UTC | #2 
Hi Oleg,

Thanks for the check!

On 2024-01-29 15:26, Sharlatan Hellseher wrote:
> One note - you introduced a module cycle which was not before
> astronomy->python-science->astronomy. If the requirement of
> python-astropy is soft let's silent it for now.

Removing the python-astropy dependency should be fine for python-unyt. I
agree that avoiding module cycles would be better. If I recall
correctly, Astropy was only used in tests, because it has a similar
submodule dealing with physical units.

The build was successful and the cycle did not show up in the linter.
How did you find it? Did you happen to notice it when you saw the imports?

Best wishes,

Troy
Sharlatan Hellseher Jan. 29, 2024, 5:31 p.m. UTC | #3 
Hi,


How did you find it? Did you happen to notice it when you saw the imports?
>

It's usually pops up in issues with efforts to break modules cycles
e.g.  https://issues.guix.gnu.org/54539.

I'm not quite sure how it is critical right now, but there was a discussion
that cycles in modules slow down ~guix pull~.

Let's comment astropy out with some notes about optional test dependency
and potential module cycle.

Looking forward for v2, patches look good.

If you have wider plan of upcoming patches please share to coordinate
efforts ;-).

Regards,
Oleg
Troy Figiel Jan. 29, 2024, 6:13 p.m. UTC | #4 
Now that you mention it, there are quite a few cycles. To name a few:

- astronomy->python-science->python-xyz->astronomy
- databases->python-xyz->databases
- bioinformatics->python-science->bioinformatics

On 2024-01-29 18:31, Sharlatan Hellseher wrote:
> If you have wider plan of upcoming patches please share to coordinate
> efforts ;-).

There is only the guix-devel list, right? No Python specific list?

When it comes to the Python ecosystem, I have been looking at

- python-shap
- python-cocotb (#68153)
- ruff

Unfortunately, ruff has caused me some headaches since it uses a Rust
workspace definition. I will probably have to write guix-devel for
advice sooner or later.

I've also still had some Golang packages on my radar, since long-term I
would like to see opentofu and gotenberg included. That might be going
off-topic a bit :-)
Sharlatan Hellseher Jan. 29, 2024, 11:01 p.m. UTC | #5 
Modifications applied:

- python-unyt :: rephrase description, partly sourced and combined from
  <https://packages.debian.org/sid/python3-unyt>,
  <https://unyt.readthedocs.io/en/stable/>

- python-pyjanitor :: speed up tests with python-pytest-xdist (~x3
  faster on 16x threads), remove blank lines, disable exact tests
  related to PySpark.

Pushed as 370b79b4f5..cde0adaacd to master.

Thanks,
Oleg