Build with uv, hatchling, updated CI/pre-commit and SPEC 0 compliant package versions

[maltekuehl]

Reference Issue or PRs

Discussed with @BorisMuzellec in #412.

What does your PR implement? Be specific.

• Uses uv for package management and hatchling for building, similar to most scverse core packages.
• Updates dependencies to be in line with Scientific Python SPEC 0
• Additional checks for pre-commit
• Fixes many mypy errors that previously went undetected (this is the reason that many files are affected in this PR)
• Updates the CI pipeline to run the ruff and mypy checks, too, and to test building the package
• Removes black as it has been superseded by ruff and the old setup.py installation, which now works through pyproject.toml
• Updates documentation to include installation with uv
• Increments the version by a patch version, as no public-facing API should have been affected

There is some debate about whether to commit uv.lock files, Astral's position is YES for full reproducibility, but if you would prefer this to not be committed, please let me know. Downside is that if this is committed, the CI does not test against the latest version of all dependencies but against the locked one, unless --upgrade is passed. Passing this option would also be a possible solution to this question.

[BorisMuzellec]

Thanks a lot @maltekuehl for this PR, that's amazing!

It's looking good. Re the last point I'm happy to follow Astral's recommendation to push the lock file, but in that case I think we should indeed test against latest dependencies using the --upgrade flag to make sure we anticipate future changes and deprecations.

Happy to merge after that!

[Zethson]

I don't think that a library like PyDESeq2 needs a lock file. It's not an app that is deployed on the web that needs fixed versions. All scverse packages are also tested without a lock file. We even have a pre-release CI job so that we test against pre-releases.

In my humble opinion, the lock file will either:

1. Give you a false sense of security that PyDESeq2 is compatible with the latest versions (not using --upgrade) OR
2. Not be necessary because you're using --upgrade which is kind of equivalent in the CI to not providing it at all in the first place

(this PR is great!)

[maltekuehl]

Thanks for the feedback to both @Zethson and @BorisMuzellec. Apologies for no progress on this issue, currently on holidays with limited internet and compute access. Will fix the mypy error (probably just a minor version difference) once back to get this merged asap.

[maltekuehl]

Fixed! Ready to merge from my side now, please let me know if there's anything I missed.

[BorisMuzellec]

Thanks a lot @maltekuehl for this PR and @Zethson for your comments! I hope I didn't miss anything because this PR is quite big but I think it's ready to be merged.

[maltekuehl]

I also checked the tutorial scripts from the docs to have another layer apart from tests to make sure there was no accidental change. So at least for common paths, I have high confidence and everywhere else, I tried to keep changes to a minimum. The typing fixes also should have addressed some minor bugs outside the standard workflows. Thanks both for the feedback and for merging. Will try to adapt the pytximport scaling PR to not have merge conflicts as well, but currently a bit swamped (as usual) so might take some weeks. If you have any comments and guidance on that one already, I would be happy to address them when addressing the merge conflicts.