Custom PEP517 builder for RAPIDS
Project description
RAPIDS PEP517 build backend
rapids-build-backend
is an adapter around PEP517 builders that provides support for key RAPIDS requirements.
It currently support scikit-build-core
and setuptools
as the wrapped builder.
The package's primary purpose is to automate the various bits of preprocessing that are typically done to RAPIDS package metadata prior to publishing packages.
This includes the following notable changes:
- Running
rapids-dependency-file-generator
to get the dependencies for the CUDA version and architecture. - Modifying the package name to include CUDA suffixes.
- Updating the git commit embedded in the importable package.
Since some of these modifications are only desirable in certain scenarios (wheel vs conda builds vs editable installs), all of these functions are customizable via the project's configuration in pyproject.toml.
In cases where more dynamic customization is sensible, suitable environment variables and config_settings
are supported during builds of distributions.
Supported configuration
Any option without a default is required.
Option | Definition | Type | Default | Supports dynamic modification |
---|---|---|---|---|
build-backend |
The wrapped build backend (e.g. setuptools.build_meta ) |
string | N | |
commit-file |
The file in which to write the git commit hash | string | "" (No file) | N |
dependencies-file |
The path to the dependencies.yaml file to use |
string | "dependencies.yaml" | Y |
disable-cuda-suffix |
If true, don't try to write CUDA suffixes | bool | false | Y |
matrix-entry |
A ; -separated list of = -delimited key/value pairs |
string | "" | Y |
require-cuda |
If false, builds will succeed even if nvcc is not available | bool | true | Y |
requires |
List of build requirements (in addition to build-system.requires ) |
list[str] | [] | N |
Outstanding questions
- How should we split up build requirements between
build-system
andtool.rapids-build-backend
? In theory any dependency that doesn't need suffixing could also go intobuild-system.requires
. I think it's easier to teach that all dependencies other thanrapids-build-backend
itself should to intotool.rapids-build-backend
, but I don't know how others feel.
Future improvements
- When https://github.com/rapidsai/dependency-file-generator/pull/48 is completed we can make dfg a dependency of this builder and use it to rewrite the dependency list instead of the manual logic here.
Rejected ideas
- We could also include the rewrite of VERSION that we use for RAPIDS builds, but this is really more specific to our release process than the general process of building our wheels. I don't think someone building a wheel locally should see the same version as what we produce via CI. If we really wanted we could pull dunamai as a dependency and write a different version here, though.
Project details
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distributions
Built Distribution
File details
Details for the file rapids_build_backend-0.1.1-py3-none-any.whl
.
File metadata
- Download URL: rapids_build_backend-0.1.1-py3-none-any.whl
- Upload date:
- Size: 12.9 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? No
- Uploaded via: twine/5.0.0 CPython/3.10.12
File hashes
Algorithm | Hash digest | |
---|---|---|
SHA256 | 6086f398726646faedb894b9881719a79f7cecdc7eae1745f2973d8fa5dc2550 |
|
MD5 | 559becc5b5e9ddf310d4b68c96023856 |
|
BLAKE2b-256 | 28213898cef44a7323b19862d6dfb0cce4050a1c0fd4577002e51c346816cadf |