Update dependencies as per SPEC0

[Armavica]

Description

https://scientific-python.org/specs/spec-0000/

• set sphinx>=5.3
• set numpy>=1.24
• set scipy>=1.9
• set filelock>=3.8
• set setuptools>=63.0
• set types-setuptools>=63.0
• set pytest>=7.2
• set pytest-mock>=3.9
• set pygments>=2.13
• set pre-commit>=2.20
• set coverage>=6.5
• set llvmlite>=0.38

Related Issue

• [ ] Closes #
• [ ] Related to #

Checklist

• [x] Checked that the pre-commit linting/style checks pass
• [ ] Included tests that prove the fix is effective or that the new feature works
• [ ] Added necessary documentation (docstrings and/or example notebooks)
• [x] If you are a pro: each commit corresponds to a relevant logical change

Type of change

• [ ] New feature / enhancement
• [ ] Bug fix
• [ ] Documentation
• [x] Maintenance
• [ ] Other (please specify):

[maresb]

This is something I care a lot about and am very eager to implement, but I have a some of questions...

1. Where are the lower bounds coming from that aren't explicitly mentioned in SPEC0?
2. Is there a particular purpose for putting lower bounds on the development dependencies? I think of development dependencies as very separate from core dependencies.
3. Is there any particular motivation for these lower pins besides SPEC0 standardization?
4. How will these be updated going forward?

I've been thinking about how to exercise the lower bounds, and I'm pretty excited about https://github.com/mamba-org/rattler/pull/660. I've been meaning to play round with rattler's Python bindings to see how hard it would be to actually hand-build some automation for this.

[Armavica]

Thank you for the comments!

1. I ran this script on all our dependencies (assuming we want a similar strategy for non-core libraries as for core scientific libs, which is maybe not a good assumption).
2. No particular purpose, just for completeness, but I agree with you that treating them differently would make sense too.
3. I would say that it allows the use of more recent features from these dependencies. Maybe also limit the variety of configurations that people may have on their machines. It might also remind us to anticipate September 2025 which is when the spec recommends to drop support for numpy 1.26 (the last version before numpy 2.0).
4. I don't know how they will be updated, but on other projects, I update dependencies once a month manually, following the output of the script above. This might not be optimal. An automated solution would be great!