Adding a non-metadata installer-only `dev-dependencies` table to pyproject.toml

Packaging
61

As part of Support enriched metadata by brettcannon · Pull Request #686 · pypa/packaging · GitHub , I analyzed a METADATA file from as many projects as I could on PyPI (thanks PEP 658 and PEP 691 !). By the far biggest validation failure was people specifying core metadata version 2.0 which never existed.

But after that was probably people with now-invalid-thanks-to-PEP-685 extra names. While some of them followed some pattern that suggested they were being used a markers for some tool, a bunch of them were due to people prefixing the extra names to mark them as private, e.g., _test. So there does seem to be some desire out there for some way to specify development dependencies in pyproject.toml and people are reverting to optional-dependencies due to the lack of any official support.

5 Likes
62

I hate to bring this up again after such a long while, but after reading through dev dependencies in pyproject.toml, searching for any new updates for this specific issue, and reading this thread again I am wondering where we stand on some potential future for this.

I quite like the proposal as discussed by @uranusjr here, or literally any other way including just throwing the dev. dependencies into the what-eventually-will-be-public namespace for extras on a package ala optional-dependencies.

The usecase here is one of simplified tooling, new user onboarding, and custom tooling to manage the current “73”

Summary

(I feel like when I look at the landscape of projects, the top level workspace is cluttered with many .$tool-config, requirements.$thing.txt, etc.)

requirements-*.txt files or tool.*.dev-dependencies.

The benefits of this include enhancing the ecosystem coherence and (imo nicely) simplifying developer experiences, which cannot be overstated. Emergent tooling (re: rye and uv) give hope to a unified option in the ecosystem but that hope trickles upstream into the orators of the Python packaging standards.

So… I advocate for the drafting of a PEP to formalize this proposal (I’d love to help!)… if we can move beyond our current stale discussions to implementation, addressing any lingering questions/stalemates, we would be fulfilling a widely acknowledged need within our community.

again, sorry for the necro post - but I have yet to find a newer discussion or movement elsewhere on what I feel to be an exciting feature addition/standardization cemented

63

@JacobCoffee, there is a very advanced proposal being worked on right now:

Or did I get things mixed up?

2 Likes