Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add debugging messages and configurable verbosity #24

Open
jameslamb opened this issue May 7, 2024 · 3 comments
Open

Add debugging messages and configurable verbosity #24

jameslamb opened this issue May 7, 2024 · 3 comments
Labels
feature request New feature or request

Comments

@jameslamb
Copy link
Member

While working through rapidsai/rmm#1502, I've found myself struggling to debug problems of the form "rapids-build-backend isn't doing what I want, but also isn't raising any warnings or errors".

It'd be helpful to be able to turn on debug-level logging and see exactly what the library is doing.

For example, I'd like to be able to use logs to inspect what's happening in here:

for file_key, file_config in parsed_config.files.items():
if (
rapids_dependency_file_generator.Output.PYPROJECT
not in file_config.output
):
continue
pyproject_dir = os.path.join(
os.path.dirname(config.dependencies_file),
file_config.pyproject_dir,
)
if not (
os.path.exists(pyproject_dir)
and os.path.samefile(pyproject_dir, ".")
):
continue
matrix = _parse_matrix(config.matrix_entry) or dict(file_config.matrix)
if cuda_version is not None:
matrix["cuda"] = [f"{cuda_version[0]}.{cuda_version[1]}"]
rapids_dependency_file_generator.make_dependency_files(
parsed_config=parsed_config,
file_keys=[file_key],
output={rapids_dependency_file_generator.Output.PYPROJECT},
matrix=matrix,
prepend_channels=[],
to_stdout=False,
)

References

Some related conversations:

@jameslamb jameslamb added the feature request New feature or request label May 7, 2024
@vyasr
Copy link
Contributor

vyasr commented May 8, 2024

One way to do this would be to use the logging module and configure log levels using an environment variable. It's tricky because the build frontend has most of the control of how the backend is invoked, so you really have to use an environment variable or something similar to control the log levels because you can't force any information to be passed via the CLI/API.

@jameslamb
Copy link
Member Author

so you really have to use an environment variable or something similar to control the log levels

rapids-build-backend could expose configuration for logging verbosity that's passed through config-settings from pyproject.toml, just like scikit-build-core does with cmake.verbose.

like this

[tool.rapids-build-backend]
log-level = "DEBUG"

@vyasr
Copy link
Contributor

vyasr commented May 8, 2024

Yup that would work. RBB supports configuration, and ~all config variables in pyproject.toml may be overridden with config settings or an env var.

KyleFromNVIDIA pushed a commit that referenced this issue May 15, 2024
## Description

Contributes to rapidsai/build-planning#31.

Related to #24.

This proposes the following changes:

* if the file indicated by `dependencies-file` does not exist, emit a
warning

## Notes for Reviewers

### Why add this warning?

While testing rapidsai/cudf#15245, I observed
`rapids-build-backend==0.1.1` failing to update the build dependencies
of wheels.

This showed up with errors like the following:

```text
ERROR: Could not find a version that satisfies the requirement rmm==24.6.* (from versions: 0.0.1)
```

It took me maybe an hour to figure out what was going on.... I wasn't
setting `dependencies-file` in the `[tool.rapids-build-backend]`
configuration.

`cudf` is laid out like this:

```text
cudf/
|___python/
       |_____cudf/
                  |_________pyproject.toml
       |_____dask_cudf/
                  |_________pyproject.toml
```

Not setting `dependencies-file` meant that `rapids-build-backend`
defaulted to `"dependencies.yaml"` (e.g.
`cudf/python/cudf/dependencies.yaml`).

That file doesn't exist, and so it just silently skipped all
`dependencies.yaml`-related stuff via this:


https://github.com/rapidsai/rapids-build-backend/blob/97a19504201f18cfae1864c8be99c1d73cbcc0f9/rapids_build_backend/impls.py#L170-L175

With the warning added in this PR, I would have at least had a hint from
CI logs pointing me at the potential problem.

### ~Why change the default?~

<details><summary>edited: removed (click me)</summary>

`"./dependencies.yaml"` (e.g., `dependencies.yaml` located next to the
wheel's `pyproject.toml`) is not a working default for any RAPIDS
project, as far as I know.

In my experience, most of them are either laid out like `cuml`:

```text
cuml/
|____dependencies.yaml
|____python/
         |_____pyproject.toml
```

Or like `rmm`

```text
rmm/
|____dependencies.yaml
|____python/
         |_____librmm
                    |_____pyproject.toml
         |_____rmm
                    |______pyproject.toml
```

See
https://github.com/search?q=%22%5Bproject%5D%22+org%3Arapidsai+path%3Apyproject.toml&type=code.

Changing to `../dependencies.yaml` would at least automatically work for
some projects (like `cuml`) with minimal risk of reaching up outside of
the repo to some other project's `dependencies.yaml` (which would be
more of a risk with, say, `../../dependencies.yaml`.

</details>

### Could we just make this a hard error instead of a warning?

I think we should!

I'd personally support being even stricter at this point in development
and making an existing `dependencies.yaml` file a hard requirement for
running `rapids-build-backend`, meaning:

* no default value for `dependencies-file`
* loud runtime error if the file pointed to by `dependencies-file`
doesn't exist

If we can't think of an existing case that requires running this without
a `dependencies.yaml`, then I think we should implement this stricter
interface. Making something more flexible later is always easier than
making it stricter, and this strictness right now will save some
developer time (e.g. would have saved me some time working on `cudf`
today).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants