Skip to content

Commit e19b825

Browse files
authored
Document naming conventions in README
1 parent febeb6b commit e19b825

File tree

1 file changed

+40
-6
lines changed

1 file changed

+40
-6
lines changed

README.md

Lines changed: 40 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -56,8 +56,8 @@ files:
5656
all: # used as the prefix for the generated dependency file names for conda or requirements files (has no effect on pyproject.toml files)
5757
output: [conda, requirements] # which dependency file types to generate. required, can be "conda", "requirements", "pyproject", "none" or a list of non-"none" values
5858
conda_dir: conda/environments # where to put conda environment.yaml files. optional, defaults to "conda/environments"
59-
requirements_dir: python/cudf # where to put requirements.txt files. optional, but recommended. defaults to "python"
60-
pyproject_dir: python/cudf # where to put pyproject.toml files. optional, but recommended. defaults to "python"
59+
requirements_dir: python/cudf # where to put requirements.txt files. optional, but recommended. Used for devcontainers. defaults to "python"
60+
pyproject_dir: python/cudf # where to put pyproject.toml files. optional, but recommended. Used for wheel builds. defaults to "python"
6161
matrix: # (optional) contains an arbitrary set of key/value pairs to determine which dependency files that should be generated. These values are included in the output filename.
6262
cuda: ["11.5", "11.6"] # which CUDA version variant files to generate.
6363
arch: [x86_64] # which architecture version variant files to generate. This value should be the result of running the `arch` command on a given machine.
@@ -99,6 +99,8 @@ files:
9999

100100
When `output: none` is used, the `conda_dir`, `requirements_dir` and `matrix` keys can be omitted. The use case for `output: none` is described in the [_Additional CLI Notes_](#additional-cli-notes) section below.
101101

102+
If more than one `files` key specifies the same output and *_dir, their contents are merged. This is how different sections are written to a given output file.
103+
102104
#### `extras`
103105

104106
A given file may include an `extras` entry that may be used to provide inputs specific to a particular file type
@@ -109,17 +111,15 @@ Here is an example:
109111
files:
110112
build:
111113
output: pyproject
112-
includes: # a list of keys from the `dependencies` section which should be included in the generated files
113-
- build
114114
extras:
115115
table: table_name
116116
key: key_name
117117
```
118118

119119
Currently the supported extras by file type are:
120120
- pyproject.toml
121-
- table: The table in pyproject.toml where the dependencies should be written. Acceptable values are "build-system", "project", and "project.optional-dependencies".
122-
- key: The key corresponding to the dependency list in `table`. This may only be provided for the "project.optional-dependencies" table since the key name is fixed for "build-system" ("requires") and "project" ("dependencies"). Note that this implicitly prohibits including optional dependencies via an inline table under the "project" table.
121+
- table: The table in pyproject.toml where the dependencies should be written. Acceptable values are "build-system", "project", "project.optional-dependencies", and "tool.rapids-build-backend"
122+
- key: The key corresponding to the dependency list in `table`. This may only be provided for the "project.optional-dependencies" or "tool.rapids-build-backend" table since the key name is fixed for "build-system" ("requires") and "project" ("dependencies"). Note that this implicitly prohibits including optional dependencies via an inline table under the "project" table.
123123

124124
### `channels` Key
125125

@@ -223,6 +223,40 @@ dependencies:
223223
- pytest
224224
```
225225
226+
## Naming conventions
227+
228+
With non-trivial collections of files and dependencies, names can look very related and become hard to distinguish. Some general guidelines that will help keep things more understandable:
229+
230+
### Patterns for [RAPIDS build backend](https://github.com/rapidsai/rapids-build-backend)
231+
232+
RBB builds generally include at least two sections:
233+
234+
```
235+
files:
236+
# This dependency brings in RBB
237+
py_build_<something>:
238+
output: pyproject
239+
extras:
240+
table: build-system # This is the thing to match with the py_build_* name
241+
includes:
242+
- <rapids_build_skbuild>
243+
# This dependency expresses the build-time dependencies for your recipe (what might otherwise go in [build-system] when not using RBB)
244+
py_rapids_build_<something>:
245+
output: pyproject
246+
extras:
247+
table: tool.rapids-build-backend # This is the thing to match with the py_rapids_build_* name
248+
key: requires
249+
includes:
250+
- <normal_project_build_time_deps>
251+
```
252+
253+
### Patterns for dependencies
254+
255+
To help distinguish dependency specifications from file specifications, it is recommended to prefix dependency entries
256+
with `dep_<type>_<name>`, where type is one of `build`, `run`, or `test`. This is functionally superfluous, as the `extras.table`
257+
value will ultimately determine where the dependency entries will go, but following the convention will make your dependencies.yaml
258+
file easier to follow.
259+
226260
## How Dependency Lists Are Merged
227261

228262
The information from the top-level `files` and `dependencies` keys are used to determine which dependencies should be included in the final output of the generated dependency files.

0 commit comments

Comments
 (0)