Infrastructure cleanup

[Darlokt]

Hej evreyone,

I have a project depending on this project and saw there is some cleanup potential in preparation for some bigger refactors/cleanups.

This is a patch series cleaning up the projects infrastructure. Removing/consolidates unnecessary/no longer used files/configs and updating tool configs etc. in preparation for a general cleanup/restructure.

Changes:

• Deleted .bumpversion.cfg as it is not used in the project.
• Deleted .mypy.ini and integrated it into pyproject.toml under the tool.mypy section.
  • Bumped the python version to 3.11 in the mypy configuration to reflect the minimum supported version.
• Updated .pre-commit-config.yaml to remove unused hooks and dependencies.
  • Removed the mirrors-prettier hook as it is conflicting with ruff and .editorconfig settings.
  • Removed the check-ast, end-of-file-fixer, mixed-line-ending and trailing-whitespace hooks as they are redundant with ruff.
  • Removed unsafe fixes from ruff
• Cleaned up the pyproject.toml and updated tool configs
  • Split the tool.ruff configuration into multiple sections to improve readability and maintainability.
  • Updated the ruff to reflect the .editorconfig settings (indentation, line endings, etc.)
  • Set the ruff minimum python version to 3.11 to reflect the minimum supported version.
  • Converted optional dependencies into dependency groups in line with PEP 735, to improve the organization and clarity of the dependencies.
  • Added docstring convention to ruff linting config in line with project standards.
  • Removed pre dependency group as it is not different to the main dependencies and only used for .readthedocs.yaml.
  • Removed bump2version from the dev dependency group as it is not used in the project and abandoned.
• Updated .readthedocs.yaml
  • Removed the pre dependency group from the installation command as it is not different to the main dependencies and only used for .readthedocs.yaml.
  • Updated resolver to use uv instead of pip to install dependencies, as it is faster and works with the implemented dependency groups.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.38%. Comparing base (a63ca08) to head (d529aeb).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #400   +/-   ##
=======================================
  Coverage   63.38%   63.38%           
=======================================
  Files          26       26           
  Lines        3217     3217           
=======================================
  Hits         2039     2039           
  Misses       1178     1178           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Darlokt]

Fixed CI workflow. Updated it to work with dependency groups and replaced manual caching with actions/setup-python internal caching. Also bumped actions to newer versions.

[Zethson]

Dear @Darlokt ,

this is great! The actual solution that we should aim for is #345 which includes many of the changes & improvements that you're suggesting here. SpatialData itself needs the same treatment.
Would you be interested in tackling it this way?

Let us know if this is unclear, please.

[Darlokt]

Hej @Zethson,

sorry for the delayed response. I wanted to take a closer look at the cookiecutter repository first to better understand what adopting #345 would involve.

I in theory understand the goal of converging on a more consistent developer experience across scverse repositories, and I agree with that goal in principle. I am not yet convinced, though, that adopting the cookiecutter template as a synced structural source would be the best fit for this repository.

My main concern is that many of the relevant parts of the template seem like they would need to be excluded or overridden here. If that is the case, automated syncing may not provide much consistency in practice, while still adding another maintenance surface and making project-specific configuration harder to preserve.

Some concrete areas where the template itself has problems / I am unsure about the fit are:

• parts of the contributors guide seem outdated
• there appear to be overlapping or conflicting pre-commit / formatter configurations
• the readthedocs.yaml setup is non standard and quite fragile instead of using native uv as here
• the uv / hatch setup seems more complex than necessary for this package, and its usage is inconsistent, including in CI
• some template changes would appear to reintroduce issues addressed by this patch series
• the template structure seems more suitable for analytical tool packages than for this reader package, especially around the pl / pp / tl structure

I do think uv itself could be a good option for making the development environment more reproducible, especially with proper locking etc. What I am less convinced about is adding hatch on top of it. From what I can currently see, that adds indirection without an obvious benefit for this repository. If the main use case is shared commands or scripts, those could also be tracked explicitly in a scripts directory.

I am also a bit cautious about automated syncing via cruft. Since most synced files would likely need repository-specific changes anyway, I worry that this could make local fixes harder to maintain. I also noticed that cruft does not seem to be actively maintained, with some recent unaddressed security concerns against its dependency tree, so I would prefer to avoid adding it as an additional dependency unless the benefit is clear.

My current preference/suggestion would be to align with specific conventions explicitly where they make sense, for example documentation dependencies etc., rather than syncing this repository from the cookiecutter template.

Could you clarify which specific parts of the template you would expect to be adapted here/in spatialdata? That would help me understand whether there is a useful subset to adopt, or whether this should instead be handled as targeted improvements.

My initial idea was to perform a minimal cleanup to remove active problems interfering with development like a misconfigured mypy etc. to then in a later patch address deeper/further reaching dx concerns/restructures.

Thanks a lot for your time, and have a nice weekend!

[Zethson]

Great answer!

If there are things that you think can be improved in the template, we'd love to see updates to the template.
Yes, adopting hatch is opinionated but consistency wins here.
Yes, the repository can deviate in things like the pp, tl, .. structure.

Not adopting the template is kind of not an option.

[Darlokt]

Great, then I will get at it!

[Darlokt]

@Zethson Do you want it as part of this pull request or should I split it?