Rename rapids_build_backend to rapids-build-backend. (#4)

This PR changes the package to use "mostly dashes" except where
underscores are required (in Python identifiers).

This aligns more closely with the conventions of
https://github.com/scikit-build/scikit-build-core, if that matters.

---------

Co-authored-by: Vyas Ramasubramani <[email protected]>

.pre-commit-config.yaml

@@ -11,16 +11,16 @@ repos:
     hooks:
       - id: codespell
   - repo: https://github.com/astral-sh/ruff-pre-commit
-    rev: v0.2.2
+    rev: v0.3.2
     hooks:
       - id: ruff
         args: ["--fix"]
       - id: ruff-format
   - repo: https://github.com/rapidsai/pre-commit-hooks
-    rev: v0.0.1
+    rev: v0.0.2
     hooks:
       - id: verify-copyright
-        args: ["--target-branch", "main"]
+        args: ["--main-branch", "main"]
 
 
 default_language_version:

README.md

@@ -1,6 +1,6 @@
 # RAPIDS PEP517 build backend
 
-`rapids_build_backend` is an adapter around PEP517 builders that provides support for key RAPIDS requirements.
+`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:
@@ -29,7 +29,7 @@ Any option without a default is required.
 
 ## Outstanding questions
 
-- How should we split up build requirements between `build-system` and `tool.rapids_builder`? In theory any dependency that doesn't need suffixing could also go into `build-system.requires`. I think it's easier to teach that all dependencies other than `rapids_builder` itself should to into `tool.rapids_builder`, but I don't know how others feel.
+- How should we split up build requirements between `build-system` and `tool.rapids-build-backend`? In theory any dependency that doesn't need suffixing could also go into `build-system.requires`. I think it's easier to teach that all dependencies other than `rapids-build-backend` itself should to into `tool.rapids-build-backend`, but I don't know how others feel.
 
 ## Future improvements
 

ci/build_python.sh

@@ -11,6 +11,6 @@ rapids-print-env
 
 rapids-logger "Begin py build"
 
-rapids-conda-retry mambabuild conda/recipes/rapids_build_backend
+rapids-conda-retry mambabuild conda/recipes/rapids-build-backend
 
 rapids-upload-conda-to-s3 python

conda/recipes/rapids_build_backend/meta.yaml → conda/recipes/rapids-build-backend/meta.yaml

@@ -5,7 +5,7 @@
 {% set summary = pyproject_data.get('project', {}).get('description') %}
 
 package:
-  name: rapids_build_backend
+  name: rapids-build-backend
   version: {{ version }}
 
 source:

pyproject.toml

@@ -8,7 +8,7 @@ requires = [
 ]
 
 [project]
-name = "rapids_build_backend"
+name = "rapids-build-backend"
 version = "0.0.1"
 description = "Custom PEP517 builder for RAPIDS"
 dependencies = [

rapids_build_backend/build.py

@@ -30,7 +30,7 @@
 # - build_editable is optional, and we can't provide a safe default implementation
 #   because we won't support editable installs unless the wrapped backend does and the
 #   mere existence of the hook will change the behavior of the build frontend to think
-#   that the backend supports editable installs when rapids_build_backend only supports
+#   that the backend supports editable installs when rapids-build-backend only supports
 #   them if the wrapped backend does.
 # - prepare_metadata_for_build_wheel and prepare_metadata_for_build_editable are
 #   optional, and we can't provide safe default implementations because we won't create

rapids_build_backend/config.py

@@ -24,9 +24,9 @@ def __init__(self, dirname=".", config_settings=None):
         self.config_settings = config_settings or {}
         pyproject_data = _get_pyproject(dirname)
         try:
-            self.config = pyproject_data["tool"]["rapids_build_backend"]
+            self.config = pyproject_data["tool"]["rapids-build-backend"]
         except KeyError as e:
-            raise RuntimeError("No rapids_build_backend table in pyproject.toml") from e
+            raise RuntimeError("No rapids-build-backend table in pyproject.toml") from e
 
     def __getattr__(self, name):
         config_name = name.replace("_", "-")

rapids_build_backend/impls.py

@@ -24,9 +24,9 @@ def _get_backend(build_backend):
     except ImportError:
         raise ValueError(
             "Could not import build backend specified in pyproject.toml's "
-            "tool.rapids_build_backend table. Make sure you specified the right "
+            "tool.rapids-build-backend table. Make sure you specified the right "
             "optional dependency in your build-system.requires entry for "
-            "rapids_build_backend."
+            "rapids-build-backend."
         )
 
 
@@ -238,7 +238,7 @@ def _edit_git_commit(config):
     commit = _get_git_commit()
 
     if commit_file != "" and commit is not None:
-        bkp_commit_file = f".{os.path.basename(commit_file)}.rapids_build_backend.bak"
+        bkp_commit_file = f".{os.path.basename(commit_file)}.rapids-build-backend.bak"
         try:
             with open(commit_file) as f:
                 lines = f.readlines()
@@ -292,7 +292,7 @@ def _edit_pyproject(config):
         }
 
     pyproject_file = "pyproject.toml"
-    bkp_pyproject_file = ".pyproject.toml.rapids_build_backend.bak"
+    bkp_pyproject_file = ".pyproject.toml.rapids-build-backend.bak"
     try:
         shutil.move(pyproject_file, bkp_pyproject_file)
         with open(pyproject_file, "wb") as f:
@@ -308,11 +308,11 @@ def _edit_pyproject(config):
 # potential issues with assuming the right pyproject.toml is readable at import time (we
 # need to load pyproject.toml to know what the build backend is). Note that this also
 # prevents us from using something like functools.wraps to copy the docstrings from the
-# backend's hooks to the rapids_build_backend hooks, but that's not a big deal because
+# backend's hooks to the rapids-build-backend hooks, but that's not a big deal because
 # these functions only executed by the build frontend and are not user-facing. This
 # approach also ignores the possibility that the backend may not define certain optional
 # hooks because these definitions assume that they will only be called if the wrapped
-# backend implements them by virtue of the logic in rapids_build_backend's build module
+# backend implements them by virtue of the logic in rapids-build-backend's build module
 # (the actual build backend, which conditionally imports these functions).
 def get_requires_for_build_wheel(config_settings):
     config = Config(config_settings=config_settings)

tests/conftest.py

@@ -159,7 +159,7 @@ def pip_cache(tmp_path_factory):
 
 @pytest.fixture(scope="session")
 def wheelhouse(tmp_path_factory, pip_cache):
-    """A PEP 517 wheelhouse containing the local copy of rapids_build_backend."""
+    """A PEP 517 wheelhouse containing the local copy of rapids-build-backend."""
     wheelhouse = tmp_path_factory.mktemp("wheelhouse")
 
     # Build the rapids-builder wheel in a temporary directory where we can bump the

tests/templates/pyproject.toml

@@ -3,7 +3,7 @@
 [build-system]
 build-backend = "rapids_build_backend.build"
 requires = [
-    "rapids_build_backend[{{ rapids_build_backend_extra }}]",
+    "rapids-build-backend[{{ rapids_build_backend_extra }}]",
 ]
 
 [project]
@@ -26,7 +26,7 @@ dependencies = [
 
 {% endfor %}
 
-[tool.rapids_build_backend]
+[tool.rapids-build-backend]
 build-backend = "{{ build_backend }}"
 requires = [
 {% for require in build_requires %}