uv pip compile pyproject.toml ignores dependencies declared in setup.cfg

[SnoopJ]

Platform: Ubuntu 20.04
uv version: fef1956

Reproduction

Project files

# pyproject.toml
[build-system]
requires = ["setuptools"]
build-backend = "setuptools.build_meta"

# setup.cfg
[options]
packages = find:
install_requires=
    numpy

# setup.py
from setuptools import setup


setup(
    name="dummypkg",
    description="A dummy package",
)

uv invocation

NOTE: this invocation points directly to the uv entrypoint to work around #1623.

$ ~/.pyenv/versions/3.9.16/bin/uv pip compile pyproject.toml  # numpy dependency is ignored
Resolved 0 packages in 4ms
# This file was autogenerated by uv v0.1.4 via the following command:
#    uv pip compile pyproject.toml

Reference pip-compile (7.3.0) invocation

$ pip-compile pyproject.toml
WARNING: --strip-extras is becoming the default in version 8.0.0. To silence this warning, either use --strip-extras to opt into the new default or use --no-strip-extras to retain the existing behavior.
#
# This file is autogenerated by pip-compile with Python 3.9
# by the following command:
#
#    pip-compile pyproject.toml
#
numpy==1.26.4
    # via dummypkg (pyproject.toml)

[SnoopJ]

Note: uv pip install does support this metadata layout, but the inconsistency is quite surprising, and this was the very first issue I ran into with uv.

Moving the dependency declaration into pyproject.toml resolves the problem, but this excludes the setuptools workflow and delivers poorly on a "drop-in" experience.

[charliermarsh]

Thanks, I'll take a look at this. (Right now, we just read the dependency information directly from the pyproject.toml.)

[charliermarsh]

So it looks like pip-tools will actually perform a PEP 517 call when passed a pyproject.toml, to determine the dependencies for the project. That's... interesting. It's a departure from my understanding of how it worked, but we of course have the capability to do that too.

[sbidoul]

This could be solved similarly to #2029.

[zanieb]

@sbidoul I don't think so, that issue uses a dynamic value in the pyproject.toml as a hint to reinstall. Here we need to add PEP 517 calls to determine dependencies in some cases (rather than just reading them all directly from the file), but I don't see a key suggesting they're dynamic. Although there is a key in #1644 it doesn't seem to apply in all cases.

[sbidoul]

@zanieb in this case it is the absence of a [project] table that signals that all metadata is dynamic and a PEP 517 metadata preparation is required to obtain it.

[charliermarsh]

👍 Might be two things here: (1) making it possible to run PEP 517 hooks for these, and (2) adding detection based on whether it’s dynamic.

[charliermarsh]

I'll be looking into this tomorrow.

[charliermarsh]

Now in review here: #2633. Expect it to be supported in the next release.