Support Pixi projects configured with pixi.toml files?

[jherland]

Triggered by #453 and largely related to #447.

Pixi is a new package management tool that appears to be designed to replace Conda. In addition to supporting project configuration in pyproject.toml (as discussed in #453), it also allows projects to be configured in its own pixi.toml file format.

Similar to other modern package management tools, Pixi preaches a clean split between direct/intentional dependency declarations (in pyproject.toml or pixi.toml) and pixi.lock lockfiles that encompass the transitive closure of dependencies.

From FawltyDeps' POV, given this clear philosophy and modern approach, Pixi appears to be easier to support than Conda. However, given its strong ties to (and clear preference for) the conda package ecosystem, there are still some common conda-related challenges to build this support into FawltyDeps:

• Understand the differences between Conda packages and "regular" Python packages (i.e. what are called PyPI packages in the Pixi/Conda community)
• Understand the differences between Conda environment and other Python environments (e.g. virtualenvs), including the existence of non-Python components inside such an environment, and how the Python environment embedded inside the Conda environment might differ from other Python environments.
• Teach FawltyDeps to:
  • Understand a Conda dependency declaration
  • Navigate a Conda environment to find the corresponding Conda package definition
  • Map this into zero or more Python packages that are provided by this Conda package
  • Further map these Python packages through the embedded Python environment into zero or more import names

The above steps clearly depend on FD having access to an actual local Pixi/Conda environment. The way FawltyDeps handles mapping package names to import names today will probably need some rework:

• It probably does not make sense to satisfy a conda dependency with an import name found via a Python package installed in a NON-conda environment.
• If we are to support --install-deps for Pixi/Conda projects, we will probably have to rely on Pixi/Conda itself to create/populate these environments.
• Other mapping approaches supported by FawltyDeps (e.g. the identity mapping, or looking at the sys.path in FawltyDeps' own environment) may or may not make sense in the context of a Pixi/Conda project.