Support "nested pixi dependencies" (for git dependencies)

[Zaubeerer]

Problem description

Problem

I have a package B, with the following pyproject.toml:

[build-system]
requires = ["setuptools >= 61.0"]
build-backend = "setuptools.build_meta"

[project]
name = "core"
version = "0.0.1"
description = "core package"
requires-python = ">=3.9, <3.11"

[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["win-64", "linux-64", "osx-64", "osx-arm64"]

[tool.pixi.pypi-dependencies]
package_a = { git = "ssh://git@github.com/package_a.git", rev = "asdfasdfasfd" }
core = { path = ".", editable = true }

It installs the git dependency package_a, which itself has the following pyproject.toml:

[project]
name = "package_a"
version = "0.1.0"
description = "Add a short description here"
requires-python = "< 3.11"
dependencies = []

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

[tool.pixi.project]
channels = ["conda-forge"]
platforms = ["osx-arm64", "linux-64", "win-64"]

[tool.pixi.pypi-dependencies]
package_a = { path = ".", editable = true }
ortools = "*"

[tool.pixi.tasks]

[tool.pixi.dependencies]
pip = ">=24.0,<25"
pytest = ">=8.2.2,<8.3"
python-dotenv = "*"

However, it seems like ortools and python-dotenv are not installed in the environment created with package_b that installs package_a as dependency.

The package_a dependencies are only installed in the environment created when running pixi install in package_a directly.

I just created a minimal reproducible example as screenshot:

Current workarounds

1. "pip dependencies"
   • OK, another way would be to add the dependencies as dependencies=[] in normal pyproject.toml format, not leveraging pixi. In that case, the dependencies would be superseded by the pixi dependencies if additionally added in the [pypi.dependencies], but only, when installing the pyproject.toml directly, not as dependency.
2. "setting all dependencies in the top level pixi pyproject.toml"
   • This is not very clean, but does the job and avoids pip related dependency resolution problems.
3. publishing the packages to

Proposed solution

It would be great if one can just reference the respective git revision as dependency and pixi resolves the packages iteratively based on the pixi dependencies.

[ruben-arts]

This is a really high value idea indeed, we previously tempt to refer to this feature as "workspaces" which in theory do exactly this but then from a path instead of a git dependency.

Here is my reply to the discussion (from already some time ago) https://github.com/prefix-dev/pixi/discussions/387#discussioncomment-7253056

What we might already implement more quickly instead of the full building logic mentioned in the discussion is the retrieval of the dependencies from a source dependency, like we can for pypi-dependencies without building it first. Currently you can only depend on a conda or pypi project and a pixi project is neither but rather a combination.

This comment solves nothing, just giving some background information.

[Zaubeerer]

Thanks for the quick answer!

The linked discussion #387 indeed relates to our problem.

What we might already implement more quickly instead of the full building logic mentioned in the discussion is the retrieval of the dependencies from a source dependency, like we can for pypi-dependencies without building it first. Currently you can only depend on a conda or pypi project and a pixi project is neither but rather a combination.

This sounds great and would likely solve the problem described in the above issue description! 👌