Open
Conversation
Migrate both packages (dbt-autofix and dbt-fusion-package-tools) from
pdm-backend to hatchling with uv-dynamic-versioning for git-based
dynamic versioning. This removes custom Python build hooks in favor of
declarative TOML configuration.
Changes:
- Replace pdm-backend build-system with hatchling + uv-dynamic-versioning
in both pyproject.toml files
- Delete pdm_build.py (root) and packages/dbt_fusion_package_tools/pdm_build.py
which contained custom version formatting and dependency pinning logic
- Configure [tool.hatch.metadata.hooks.uv-dynamic-versioning] to template
dbt-fusion-package-tools=={{ version }} at build time, replacing the
pdm_build_initialize() hook that conditionally pinned the dependency
Tradeoffs and things to know:
The hatch metadata hook requires that `dependencies` be listed in
`dynamic` and NOT appear in [project]. This means ALL dependencies —
not just the templated dbt-fusion-package-tools — had to move from
[project].dependencies into the [tool.hatch.metadata.hooks.uv-dynamic-versioning]
dependencies list.
As a consequence, `uv add <pkg>` no longer works for the root dbt-autofix
package. New dependencies must be manually added to the
[tool.hatch.metadata.hooks.uv-dynamic-versioning].dependencies list in
pyproject.toml, then `uv lock` run to update the lock file. `uv add`
still works for the dbt-fusion-package-tools sub-package since it does
not use the metadata hook.
The old pdm_build.py only pinned dbt-fusion-package-tools on "real
releases" (skipping .post, .dev, rc, alpha, beta versions). The new
{{ version }} template always pins to the resolved version. This is
acceptable because in practice, only tagged releases are published to
PyPI, and the version will always resolve correctly in that context.
Local development is unaffected — uv workspace source resolution
(`[tool.uv.sources]` with `workspace = true`) still takes precedence
over the declared dependency version, so local changes to
dbt-fusion-package-tools are picked up automatically by dbt-autofix
during development.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Per the uv-dynamic-versioning tips documentation [1]: - Set fallback-version = "0.0.0" so builds don't fail in non-git contexts (e.g. Dependabot running `uv lock --upgrade-package` in a shallow clone that lacks git tags). - Set cache-keys with git commit and tag tracking so uv invalidates its aggressive metadata cache when git state changes. Without this, uv may serve stale version metadata after new tags or commits. [1] https://github.com/ninoseki/uv-dynamic-versioning/blob/main/docs/tips.md Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The test_core_1_10_installation and test_core_1_12_installation nox sessions used `uv add` to install dbt-core into the test venv. This fails now because [project].dependencies is dynamic (managed by the uv-dynamic-versioning metadata hook), and `uv add` tries to write to [project].dependencies which conflicts with the dynamic field. Replace `uv add` with `uv pip install` since these sessions only need dbt-core present in the venv to verify compatibility — they don't need it as a permanent project dependency. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The old session ran `pre-commit try-repo .` which fails with the
uv-dynamic-versioning metadata hook: the hook pins
dbt-fusion-package-tools=={version}, and in dev the version (e.g.
0.18.7.post11.dev0+e7aee63) doesn't exist on PyPI. This is not a
real-world problem — users always pin a tagged release in their
pre-commit config, where the version exists on PyPI.
The new test_wheel_installation session exercises more than the old one:
1. Builds both wheels via `uv build --all`
2. Inspects the dbt-autofix wheel to verify pre_commit_hooks/ is included
3. Verifies the metadata contains dbt-fusion-package-tools=={version}
4. Installs both wheels in an isolated (non-workspace) venv
5. Runs the CLI entry point (dbt-autofix --help)
6. Runs the pre-commit hook entry point (python -m pre_commit_hooks.check_deprecations)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
I do think it's still a good quality check to keep before we upload to pypi. Let's fully build the wheel and make sure it contains what we think it will
This mirrors what we were doing with our pdm script but using dunami's declarative config. Great find Chaya!
…ing/292/remove-pdm-build
Create a local-only git tag. Build wheels. Test that the tag was used! Now both the dev build and release build flows are tested - i.e., both sides of the jinja if/else for our dynamic versions Had to refactor to the wheel creation / installation logic to share between both tests
…ing/292/remove-pdm-build
maintainers, authors, and homepage
Now assert that both packages are built and have the correct version (unpinned for dev, pinned to expected version based on git tag for release)
We were re-exporting everything at first, but I want to be much more careful. Tests import from subpackages where needed. But my goal is for dbt-autofix to only need to import from top-level
davidharting
changed the title
…ing/291/jinja-parsing-subpacke
Matches the same setting in dbt-fusion-package-tools and root pyproject.toml, which suppresses the commit ID from version strings — required for TestPyPI. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Resolves #291.
Move code related to jinja-parsing to it's own sub-package.
I tried to keep this minimal.
Decisions
dbt-autofix-jinja. I wanted it to be clear that this package supports autofix, and is not a general jinja package maintained by dbt. If we haddbt-jinja, or similar, I'm afraid people would assume it's like dbt-flavored jinja, or our own official jinja parser or something.Type of change
Checklist
uvx ruff@0.14.14 check . --config pyproject.tomluvx ruff@0.14.14 format --config pyproject.toml