Add more optional test dependencies

[LecrisUT]

• full-test to include all functional dependencies, e.g. numpy required for test-fortran
  • numpy
  • hatch-fancy-pypi-readme
  • setuptools-scm
• self-consistent(-test) to include all packages that are required to run in a python-only environment, e.g. PyPI's cmake
  • cmake
  • ninja

Of course with more appropriate names

[LecrisUT]

That's a bit unintuitive to have them all in [dev] dependencies, like shouldn't pre-commit be in there instead? I think it would be cleaner to have nested dependencies and/or aliases like:

test-full = [
    "scikit-build-core[test]",
    "hatch-fancy-pypi-readme",
    "numpy; python_version<'3.12' and platform_python_implementation!='PyPy'",
    "numpy~=1.21.0; python_version=='3.7' and platform_python_implementation=='PyPy' and sys_platform == 'linux'",
    "numpy~=1.24.0; python_version=='3.8' and platform_python_implementation=='PyPy'",
    "numpy~=1.25.0; python_version=='3.9' and platform_python_implementation=='PyPy'",
    "rich",
    "setuptools-scm",
]

I don't know if the packaging system will allow for cmake and ninja as tests requirements since these are not built or aliased to be python packages in fedora and I don't know if the macro can search for system packages there as well. Usually it would search for python3-cmake package.

[henryiii]

IIRC extra normalization isn't well defined, so I try to avoid dashes in extras until that's worked out. Self dependencies aren't supported on older versions of Pip, so for now I'm avoiding those too, and just expecting someone using extras to list several extras.

IMO, pre-commit is an app, and should never be installed into the same environment as the package. In that sense, "dev" can't be an extra - it's always an environment that has the main package installed into it. requirements.txt can describe a dev environment, or PDM dependencies, hatch, etc. So to me, [dev] is a broader version of "test" (but requires test too for the moment, [dev,test]). But I can rename it & split it into two.

[LecrisUT]

Oh, didn't know there could be those kind of complications. About pre-commit not being in dev, but then wouldn't you always be having the pre-commit on your local environment in the same venv environment? Or what is your workflow wrt pre-commit hooks. Using the system installed pre-commit or a separate venv invrionment?

[henryiii]

System installed pre-commit. Probably with pipx install pre-commit. Or you can run nox -s lint which will run pre-commit. In general, apps should not be in a venv with libraries. (Internally, pipx, brew, etc. generally have a venv for each app with just the CLI exposed to the system).

I went with _ because I think that's the safe one to use; any normalization of extras hopefully will normalize to _.

[henryiii]

Ahh, it's -, not _. I wish pip would support normalization too if hatch does it...