85 contains a reproducible example and details of the problem this solves. In short:

when rendering to stdout, dependency-file-generator currently defaults to looking for the file to overwrite in the current working directory
that leads to it use, say, ./pyproject.toml as the source for an invocation that should be handling e.g. ./python/cudf/pyproject.toml

This proposes the following:

modifies make_dependency_files() to always conda_dir / pyproject_dir / requirements_dir as a source of the file to load / possibly overwrite
fixes some outdated stuff in get_output_dir() docstring
changes get_output_dir() to use keyword-only arguments
adds a test covering this functionality

Notes for Reviewers

How I tested this

Installed the version from main on this branch.

git checkout main -- src/rapids_dependency_file_generator/_rapids_dependency_file_generator.py
pip install --ignore-installed .

Confirmed that this new unit test fails on main, and is reading in the root-level pyproject.toml instead of the nested one.

pytest tests/test_rapids_dependency_file_generator.py

Confirmed that it fails with the same error as #85 on the new test project added here.

cd ./tests/examples/nested-pyproject
rapids-dependency-file-generator \
   --output pyproject \
   --file-key sparkly_unicorn \
   --matrix "cuda=100.1"

# tomlkit.exceptions.NonExistentKey: 'Key "project" does not exist.'

Tested on cudf's actual dependencies.yaml on branch-24.06.

rapids-dependency-file-generator \
  --output pyproject \
  --file-key py_run_cudf \
  --matrix "cuda=12.2"

rapidsai / dependency-file-generator

fix: support rendering nested pyproject.toml outputs to stdout #86

85 contains a reproducible example and details of the problem this solves. In short:

Notes for Reviewers

How I tested this