search

pypa / hatch

Modern, extensible Python project management
https://hatch.pypa.io/latest/
MIT License
5.83k stars 288 forks source link

Possibility to mark dependencies as dev-only that don’t go into package metadata #754

Open hynek opened 1 year ago

hynek commented 1 year ago

I like using optional dependencies like tests or docs for local development.

However, it has the annoying side-effect of putting that into package metadata which make it look like attrs depends on some wild stuff.

It would be nice to have dev-only dependency groups and my recent foray into PDM showed me there’s precedent for that: https://pdm.fming.dev/latest/usage/dependency/#add-development-only-dependencies

Syntax is the same, just different key:

[tool.pdm.dev-dependencies]
tests = ["pytest"]

FWIW, I’d be perfectly content with something like this which is less standard-bending:

[tool.hatch]
dev-only-groups = ["tests", "dev", "docs"]

I realize there’s certain overlap with hatch environments, but I don’t want to break the Python-standard ways of installing packages. At least for now (fact aside that I can’t use them for now :))

funkyfuture commented 1 year ago

what about a subcommand that let's you install the dependencies of a given environment into the currently active environment? i assume that you want to work with these packages in an interactive shell. b/c everything else can be done with environments as they are designed and implemented, is my impression.

gwerbin commented 1 year ago

What's the reason for avoiding Hatch environments? If someone else is working on your project, they'll need Hatch on their system one way or another, so I don't see the benefit in avoiding them in favor of a dev optional dependency group.

A dev-only optional dependency group seems more "standard-bending" than just using a Hatch environment, because the former actually changes the behavior of a standard feature, while the latter is a different thing altogether. The PDM dev-only dependencies are morally identical to (and less flexible than) having extra dependencies in a Hatch environment.

It is reasonable to offer tests and docs dependency groups in your published package, because downstream users might want to run tests and build docs without setting up a full dev environment. I also don't see much concern with these entering the Wheel metadata, as they explicitly are listed with an extra == condition.