Consider adding parameters to the CLI to select where a pypi dependency is added to a pyproject.toml manifest

[olivier-lacroix]

Problem description

With #2448, pixi can now read pypi dependencies (and add them to the relevant features) in a pyproject.toml manifest from:

• the [project.dependencies] array
• the [project.optional-dependencies] table
• the [dependency-groups] table
• the [tool.pixi.pypi-dependencies] table

However using pixi add --pypi will always add a pypi dependency to:

• the [project.dependencies] array if no feature / the default feature is specified
• the [dependency-groups] table if a non-default feature is specified
• unless --editable or --platform flags are used, in which case, it will be added to the [tool.pixi.pypi-dependencies] table

We may consider adding an additional flag to pixi add --pypi to allow selecting the array / table where the dependency will be added.

We could:

1. Not add any argument, and let users edit the manifest when needed
2. Add a --location argument:
   • Setting --location to pixi would force adding the pypi dependency to the [tool.pixi.pypi-dependencies] table.
   • Setting --location to optional-dependencies would force adding the pypi dependency to the project.optional-dependencies table (this will only have an effect if a non-default feature is also specified).
3. extend the CLI with --optional-dependencies [OPTIONAL_GROUP] and --dependency-group [DEPENDENCY_GROUP]. using the --feature flag would add the dependency to the [tool.pixi.pypi-dependencies] table.

A few thoughts on pros & cons:

• adding arguments (in option 2 or 3) creates argument(s) to the CLI that are valid only for a pyproject.toml manifest. This is not ideal in that regard, as (I believe?) this would be a (bad) first.
• in option 2, specifying --location optional-dependencies would only do something if a non-default feature is also specified (an error or warning could be thrown). However, that option does keep --feature as a key parameter, irrespective of the manifest, limiting the divergence in API between pyproject.toml and pixi.toml manifests
• in option 3, the API becomes simpler, but diverges more between pyproject.toml and pixi.toml manifests. Also, I feel it will become less clear to the user that using --optional-dependencies FEATURE, --dependency-group FEATURE or --feature FEATURE will do exactly the same thing from a pixi standpoint.

[SHEscher]

+1

In this line, I also observed the issue that pixi upgrade --feature ... moved dependencies from the [project.optional-dependencies] -> [dependency-groups]

#pyproject.toml
...
[project.optional-dependencies]
develop = ["pytest>=8.1", "pytest-cov>=5.0.0"]
...

Running:

pixie upgrade --feature develop pytest

results in:

#pyproject.toml
...
[project.optional-dependencies]
develop = [ "pytest-cov>=5.0.0"]
...
[dependency-groups]
develop = ["pytest>=8.3.4,<9"]
...

(minor detail: also note the white-space in [ "pytest-cov>=5.0.0"])

[SHEscher]

Maybe following uv w.r.t. the naming of flags could support consistency across tools:

"The --dev, --group, or --optional flags can be used to add a dependencies to an alternative table."

Source: https://docs.astral.sh/uv/concepts/projects/dependencies/#adding-dependencies

For pip there are similar discussions: pypa/pip#12963

[olivier-lacroix]

@SHEscher , can you reopen #2470 regarding pixi upgrade moving the dependency? This should not happen indeed.

[SHEscher]

@SHEscher , can you reopen #2470 regarding pixi upgrade moving the dependency? This should not happen indeed.

I do not have permission to do that.