Add --build-backend option to usethis init#1469
Conversation
Add a new --build-backend CLI option that allows users to choose which build backend to use when initializing a project. Supported values match those of uv init --build-backend: hatch (default), uv, flit, pdm, setuptools, maturin, scikit, and poetry. The build backend is stored in usethis_config and used by both the uv backend (passed through to uv init --build-backend) and the none backend (generates appropriate [build-system] config in pyproject.toml). Closes #347 Co-authored-by: nathanjmcdougall <18602289+nathanjmcdougall@users.noreply.github.com> Agent-Logs-Url: https://github.com/usethis-python/usethis-python/sessions/3d692c70-3b16-43c5-bd5a-8fdc2463c5f9
Co-authored-by: nathanjmcdougall <18602289+nathanjmcdougall@users.noreply.github.com> Agent-Logs-Url: https://github.com/usethis-python/usethis-python/sessions/3d692c70-3b16-43c5-bd5a-8fdc2463c5f9
--build-backend option to usethis init
…ehensiveness test Reduce BuildBackendEnum to only hatch and uv for simpler maintenance. Remove tests for flit/setuptools/poetry/etc backends. Add TestBuildSystemConfig::test_keys_match_enum to verify _BUILD_SYSTEM_CONFIG keys stay in sync with BuildBackendEnum members. Update docs/cli/reference.md to only list hatch and uv. Co-authored-by: nathanjmcdougall <18602289+nathanjmcdougall@users.noreply.github.com> Agent-Logs-Url: https://github.com/usethis-python/usethis-python/sessions/69842fd3-e51b-4d58-9bd1-fd5136923fd9
src/usethis/_init.py
Outdated
| from usethis._types.build_backend import BuildBackendEnum | ||
|
|
||
| _BUILD_SYSTEM_CONFIG: dict[BuildBackendEnum, tuple[list[str], str]] = { | ||
| BuildBackendEnum.hatch: (["hatchling"], "hatchling.build"), |
There was a problem hiding this comment.
I think I want to use the fallback versions here. We will need some logic for getting the next breaking uv release, next breaking hatchling release, etc.
There was a problem hiding this comment.
@copilot please add use the FALLBACK_UV_VERSION incl. next_breaking_uv_version rather than hard-coding here.
Likewise for hatch please add a FALLBACK_HATCHLING_VERSION and set it to 1.29.0 and write a next_breaking_hatchling_version and put it in the same module as next_breaking_uv_version. It should probably share the same implementation as next_breaking_uv_version so make a next_breaking_version helper.
Make sure to add appropriate tests
There was a problem hiding this comment.
Done in 520b090. Added FALLBACK_HATCHLING_VERSION = "1.29.0" and a generic next_breaking_version() helper in _fallback.py. next_breaking_uv_version() now delegates to it. _BUILD_SYSTEM_CONFIG uses FALLBACK_UV_VERSION/FALLBACK_HATCHLING_VERSION with next_breaking_version() for dynamic bounds. Tests added for both (TestFallbackHatchlingVersion, TestNextBreakingVersion).
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…ystem config - Add FALLBACK_HATCHLING_VERSION = "1.29.0" to _fallback.py - Extract next_breaking_version() generic helper into _fallback.py - Refactor next_breaking_uv_version() to delegate to next_breaking_version() - Update _BUILD_SYSTEM_CONFIG to use FALLBACK_UV_VERSION, FALLBACK_HATCHLING_VERSION and next_breaking_version() instead of hard-coded version bounds - Add TestFallbackHatchlingVersion and TestNextBreakingVersion tests Co-authored-by: nathanjmcdougall <18602289+nathanjmcdougall@users.noreply.github.com> Agent-Logs-Url: https://github.com/usethis-python/usethis-python/sessions/0ab118f5-5448-457b-a6aa-6740f6b46a5d
The
usethis initcommand hardcodedhatchas the build backend with no way for users to choose an alternative likeuv_build.Adds a
--build-backendCLI option supportinghatch(default) anduvas build backends.$ usethis init --build-backend uvChanges
BuildBackendEnum(src/usethis/_types/build_backend.py) — new enum withhatchanduvvaluesUsethisConfig— addedbuild_backendfield (default:hatch) with save/restore inset()context manageropinionated_uv_init()/ensure_pyproject_toml_via_uv()— readusethis_config.build_backendinstead of hardcoding"hatch"ensure_pyproject_toml()forbackend=none— uses a_BUILD_SYSTEM_CONFIGmapping to generate correct[build-system]for any backend; hatch-specific[tool.hatch.build]config now conditional onbuild_backend is hatch--build-backendoption wired throughinit()→usethis_config.set(build_backend=...)docs/cli/reference.mdupdated with possible valuesTestBuildSystemConfig::test_keys_match_enumto verify_BUILD_SYSTEM_CONFIGkeys stay in sync withBuildBackendEnummembersnext_breaking_version()(src/usethis/_fallback.py) — generic semver helper extracted fromnext_breaking_uv_version();next_breaking_uv_version()now delegates to itFALLBACK_HATCHLING_VERSION(src/usethis/_fallback.py) — new constant set to1.29.0_BUILD_SYSTEM_CONFIG— version bounds now computed dynamically usingFALLBACK_UV_VERSION/FALLBACK_HATCHLING_VERSIONwithnext_breaking_version()instead of hard-coded stringsTestFallbackHatchlingVersion(up-to-dateness) andTestNextBreakingVersion(unit tests for generic helper)Original prompt
--build-backendinusethis init#847🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.