`uv pip install --all-extras .` fail to locate `pyproject.toml`

[kdeldycke]

Using the latest version of uv:

$ uv --version
uv 0.2.21 (ebfe6d8fc 2024-07-03)

When I try to install in my local venv all extras, I get the following error:

$ uv pip install --all-extras .
error: Requesting extras requires a `pyproject.toml`, `setup.cfg`, or `setup.py` file.

Still, I have a pyproject.toml at the root, so I expect uv to use it:

$ ls -lah ./pyproject.toml
Permissions Size User Date Modified    Name
.rw-r--r--  4.5k kde  2024-07-03 10:16  ./pyproject.toml

This can be reproduced from scratch with my project with the following commands:

$ cd ~
$ git clone https://github.com/kdeldycke/mail-deduplicate
$ cd mail-deduplicate
$ uv venv
$ source .venv/bin/activate
$ uv pip install --all-extras .

This seems to be a follow up of #260.

[charliermarsh]

That API requires that you pass the pyproject.toml directly on the command line, rather than the path to the source tree — since if you’re doing the latter, there’s already standardized syntax for it (putting the extras in brackets).

[kdeldycke]

That API requires that you pass the pyproject.toml directly on the command line, rather than the path to the source tree — since if you’re doing the latter, there’s already standardized syntax for it (putting the extras in brackets).

So there is no way to tell uv to install all extras, whatever their numbers or IDs?

I tried different ways like:

$ uv pip install ".[*]"
error: Failed to parse: `.[*]`
  Caused by: Expected an alphanumeric character starting the extra name, found '*'
.[*]
  ^

$ uv pip install ".[all]"
Resolved 23 packages in 1.13s
   Built meta-package-manager @ file:///Users/kde/meta-package-manager
Prepared 1 package in 797ms
Uninstalled 1 package in 0.93ms
Installed 1 package in 2ms
 - meta-package-manager==5.17.0 (from file:///Users/kde/meta-package-manager)
 + meta-package-manager==5.17.0 (from file:///Users/kde/meta-package-manager)
warning: The package `meta-package-manager @ file:///Users/kde/meta-package-manager` does not have an extra named `all`.

[charliermarsh]

The typical thing would be to define an extra called all in your package, and recursively reference the others, like:

[project]
name = "black"

[project.optional-dependencies]
colorama = ["colorama>=0.4.3"]
uvloop = ["uvloop>=0.15.2"]
all = [
  "black[d]",
  "black[uvloop]",
]

[kdeldycke]

Oh ok I see. Thanks @charliermarsh for the hint. Now I get it. The all keyword is more like a convention than a technical feature. And so I'm pretty sure that this is not specified or enforced in any PEP XXX.

Given the diversity of packages I'm likely to stumble upon, and because I'm trying to implement the most generic reusable workflows, I prefer the safety of the --all-extras parameter.

So for example, my strategy to implement a generic mypy type checking job, consist in running the following command to get all dependencies installed, including the optional ones from the various typeshed packages:

$ uv pip install --all-extras ${{ needs.project-metadata.outputs.uv_requirement_params }}

Where needs.project-metadata.outputs.uv_requirement_params is a variable produce by my gha-utils CLI:

$ pipx install gha-utils
$ gha-utils metadata
(...)
uv_requirement_params=--requirement pyproject.toml --requirement requirements.txt --requirement requirements/yamllint.txt --requirement requirements/mypy.txt --requirement requirements/format-python.txt --requirement requirements/build.txt --requirement requirements/nuitka.txt --requirement requirements/mdformat.txt --requirement requirements/pipdeptree.txt --requirement requirements/uv.txt --requirement requirements/changelog.txt --requirement requirements/gha-utils.txt

It's quite convoluted, but it works.