Add optional deps if not using hatch

[sneakers-the-rat]

Currently if you say "no" to using hatch envs but "yes" to all the bells and whistles, you end up with a package that doesn't have the optional dependencies needed to use them :(

so this completes another leg of the combinatoric labyrinth we are constructing here ;)

for a project my_package with hatch off...

and nothing special is added:

[project.optional-dependencies]
dev = [
    "hatch",
    "pre-commit",
    "my_package[audit]",
]
audit = [
    "pip-audit",
]

and everything special is added

[project.optional-dependencies]
dev = [
    "hatch",
    "pre-commit",
    "my_package[docs,tests,style,types,audit]",
]
docs = [
    "pydata_sphinx_theme ~=0.16",
    "myst-parser ~=4.0",
    "Sphinx ~=8.0",
    "sphinx-autobuild ==2024.10.3"
]
tests = [
    "pytest",
    "pytest-cov",
    "pytest-raises",
    "pytest-randomly",
    "pytest-xdist",
]
style = [
    "pydoclint",
    "ruff",
]
types = [
    "mypy",
]
audit = [
    "pip-audit",
]

and the permutations in between.

I think this officially puts as at the time in every template's life where we need to start abstracting the values, because keeping deps synchronized will be tough.

[Midnighter]

I'm not super happy with the optional dependencies listed in dev to be honest. I think, hatch is much better installed via pipx and likely pre-commit, too.

How about we wait until dependency-groups are fully supported by hatch and then give this a go?

[sneakers-the-rat]

part of that might be differences in how we use that group/term? Between these two pyproject.tomls (the template one and the top-level one) I think i see you using them as like 'minimal' dev requirements: just enough to get you started in the environment, and then the packaging tool takes over (i didn't realize hatch had a full tox-like env system until today, i have been using pdm bc simple but now i am like :eyes-emoji: ), where i have typically used that as "everything used during development, which is usually close to everything everything." I'm a little old fashioned and haven't made pipx part of my routine yet.

So maybe we take all the other optional deps out of dev and make an all group instead?

I think it's worth doing in the short term for a few reasons:

• first is that if someone is exploring, past first steps, and wants to see how "non-hatch" works. at the moment they would just get nothing: instead of a comparison of "how does this look like in hatch vs not hatch" it would just be "having the deps vs not having them"
• relatedly, a package generated without hatch but yes on the other options would end up with a decent bit of dead/unusable code in the repo without clear path to resolve that
• i'll open a separate issue on this rn so i can know if i should stop thinking this, but i also eventually imagine it would be nice to have a choice of frontend/backend managers down the line. It would take a bit of doing, and i think we would have to give up on feature parity between all of them (e.g. hatch might have a deeper config tree that lets you do fancy hatch things), but there are some things like deps and dep groups that would need to have some representation in all frontend/backend combos. So starting to keep that division in mind early and not getting too far off in hatch-only land might make it easier later on when we want to think about other package managers.

[blink1073]

I agree with this approach, it is similar to what we've used in Jupyter libraries. Having everything self-contained has been super helpful for contributors.

[blink1073]

LGTM!

[sneakers-the-rat]

want to check with @Midnighter before merging since he expressed some reservations. is this ok or no good? :)

edit: I didn't make the switch to an all dependency group to leave dev just as hatch, but can totally do that if it's preferable.

[Midnighter]

Go ahead, we can revisit this when new features are available.

[lwasser]

@all-contributors please add @sneakers-the-rat for code, review

[allcontributors]

@lwasser

I've put up a pull request to add @sneakers-the-rat! 🎉