Preliminary support for Pixi projects using pixi.toml #456

For a Python environment to be considered valid, we typically look for a Python executable, and an associated site-packages directory. The check for the Python executable uses .is_file(), which returns true as long the Python executable is a regular file, or a symlink to an existing regular file. We are however running into occasional CI failures where the Python executables in some of our (cached) virtualenvs for real_projects appear to be broken symlinks. I suspect that environments where Python executables are broken symlinks might also occur in other circumstances (e.g. on Nix where the underlying Python executable might have been garbage-collected due to a missing GC root, or on a more regular Linux distro where a stale virtualenv might be pointing to a system Python that has since been upgraded). In any case, a Python environment with a broken python symlink might be non-functional, but should that really cause problems for FawltyDeps? Since FawltyDeps can traverse the environment without relying on the environment's Python executable, the answer is actually no: All we really need is for bin/python to serve as a marker that this is (or at some point was) a Python environment, and a broken symlink should not stop us. Hence tweak our code to take broken symlinks into account when recognizing Python environments.

This adds support for the default configuration file used in Pixi project: pixi.toml. The relevant fields in this file mirror the Pixi fields we already parse in pyproject.toml (but without the tool.pixi prefix). Thus we can reuse the parsing functions we already wrote for supporting Pixi projects via pyproject.toml.

Now that we can parse dependency declarations from pixi.toml files, we need to expose this functionality in our docs + CLI, as well as automatically find pixi.toml files while traversing projects.

This was created with the following commands: - pixi init pixi_default_example - cd pixi_default_example/ - pixi add python - pixi add --pypi requests - pixi add ninja - echo "import requests" > main.py followed by removing/truncating files that I do not currently consider to be important for FawltyDeps to make sense of this project. The result is a simple Pixi project with two declared Conda dependencies (Python itself + ninja) and one PyPI dependency (requests), along with a single source file that imports requests. The expected result of running FawltyDeps here is reporting ninja as an unused dependency. This is because ninja is a Conda package with no Python components, and since it is not found as a Python package, we fall back to the identity mapping and expect it to be imported as "ninja". We should fix this by digging into the Conda environment to discover that ninja has no Python components, and therefore is not expected to be imported.

When parsing a pyproject.toml or pixi.toml with invalid TOML data, the tomllib parser will raise an exception that is not properly caught or handled by FawltyDeps. Fix this by logging an error message and returning from the parse function. This allows FawltyDeps to continue parsing other files and reporting undeclared/unused dependencies, whereas before it would abort with a traceback.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Preliminary support for Pixi projects using pixi.toml #456

Preliminary support for Pixi projects using pixi.toml #456

Commits on Oct 7, 2024