Projects that aren't meant to generate a wheel and `pyproject.toml`

[brettcannon]

@pf_moore

Why not allow multiple sets of requirements on an equal footing, rather than making one set “special” and then advise people not to use it if they want multiple equal sets?

Because of the desire of defaults to (potentially) simplify the common case. Imagining a py run scenario, would you expect someone to always specify the dependency group they will typically use, e.g. py run -r default ..., or be able to leave that out when they don’t need it so they are just typing py run ...?

@pf_moore

If we need a “special” set, let’s just propose a distinguished name for it (like hatch does with the environment named “default”).

That’s totally fine by me. The key suggestion from me is that there is some way to say what tools should default to using when running code to avoid having to always ask the user what they want installed into their virtual environment.

@pf_moore

if people are clear on the differences, but still think there’s a need for test dependencies in [project] then that implies that it’s a valid suggestion, which we need to consider.

That’s what I’m getting at. Right now, if you have a list of test dependencies (e.g., pytest), you either have to specify it outside of your pyproject.toml via a requirements file, hope you use a workflow tool that has built-in support for this concept so you can specify it in a [tool] table, or you use an extra like test (as specified in the core metadata as a reserved extra name). I believe that last suggestion is one some folks have not loved due to it leaking out into the UX of the wheel, hence Adding a non-metadata installer-only `dev-dependencies` table to pyproject.toml . So my point is if we come up with a way to have people specify such things in this scenario, then I suspect the [project] users will also want a solution.

@pf_moore

That suggests that you view [run] as the input to a pinning process. Is that your primary motivation here, or is it simply one possible use of the section?

A possible use case.

@pf_moore

I would absolutely expect that any [run] style of proposal would need to be usable by tox/nox, as a replacement for their current custom format.

I can’t speak to Tox, but based on my use of Nox I don’t think that will be an issue. For instance, these days I put my test requirements in a “test” extra in my pyproject.toml and then have Nox do session.run(["pip", "install", "-e", ".[test]"]). That keeps the test requirements in a centralized place that any tooling can access, whether that’s Nox, CI, VS Code, etc.

@pf_moore

I’d like to understand what people are trying to do, not what they are not trying to do.

I’ll explain what I’m trying to do from the angle of a Django app, but it isn’t Django-specific in any way.

I want a way to write down the dependencies my Django app has. I can then zip up the code and deploy it to my cloud provider who can read those requirements and install my dependencies on deployment (this helps avoid having to ship my wheels, especially if I e.g. develop on Windows but deploy to Linux). FYI I’m ignoring running e.g. pip-compile to pin my dependencies in this discussion.

I also want a way to list what is necessary to run my test suite. This should be accessible by Nox, CI (although I personally use pipx run nox), and VS Code when it wants to create an environment for me. These test dependencies implicitly include what’s necessary to run the code.

I also want to be able to specify my linting tools (which includes formatters) so that I can run them in CI and also have folks run the same tooling locally. I may also want to be able to run them from VS Code in some way (e.g. tasks, using a specific version for the matching extension, etc.).

@pf_moore

I think it’s clear that pip-compile should be outputting a lockfile, and [run] should be the equivalent of the requirements.in file.

That’s my view as well.