Fix __version__ to read from package metadata instead of hardcoded string#30
Open
davidmoserai wants to merge 1 commit intoComfy-Org:mainfrom
Open
Fix __version__ to read from package metadata instead of hardcoded string#30davidmoserai wants to merge 1 commit intoComfy-Org:mainfrom
davidmoserai wants to merge 1 commit intoComfy-Org:mainfrom
Conversation
…ring
`comfy_kitchen.__version__` has been reporting "0.1.0" since the first
release, regardless of the actual installed version. This is because the
version string was hardcoded in two places:
- `comfy_kitchen/__init__.py` (line 19): `__version__ = "0.1.0"`
- `dlpack_bindings.cpp` (line 557): `m.attr("__version__") = "0.1.0";`
Neither was ever updated during version bumps — every bump commit (0.2.0
through 0.2.7) only modified `pyproject.toml`.
This causes real confusion in production environments. For example, when
debugging CUDA backend issues, runtime version checks like
`comfy_kitchen.__version__` report "0.1.0" even though pip metadata
correctly shows 0.2.7, making it appear that an old/broken version is
installed.
Fix:
- Replace the hardcoded `__version__` in `__init__.py` with
`importlib.metadata.version("comfy-kitchen")`, which reads from the
package metadata set by `pyproject.toml` — the single source of truth.
Includes a `PackageNotFoundError` fallback for editable/dev installs.
- Remove the hardcoded `__version__` from the C++ nanobind module
(`dlpack_bindings.cpp`), since the Python-level `__version__` is the
canonical source and nobody accesses `_C.__version__` directly.
Co-Authored-By: Claude Opus 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
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.
Problem
comfy_kitchen.__version__reports"0.1.0"regardless of the actual installed version. This has been the case since the first release — the version string was hardcoded in two places and never updated during any version bump:Every version bump commit (0.1.6 → 0.2.0, 0.2.2, 0.2.3, 0.2.5, 0.2.6, 0.2.7) only modified
pyproject.toml, leaving these hardcoded strings unchanged.Real-world impact
This caused significant debugging confusion in our production inference pipeline. When investigating CUDA backend issues, our startup diagnostics reported
comfy-kitchen 0.1.0at runtime. Since version 0.1.0 was the initial release with known limitations, we spent considerable time trying to force-upgrade the package — only to discover thatpip show comfy-kitchencorrectly reported 0.2.7 all along. The__version__attribute was simply wrong.The mismatch between
importlib.metadata.version("comfy-kitchen")(correct:0.2.7) andcomfy_kitchen.__version__(wrong:0.1.0) is confusing for anyone doing version checks or runtime diagnostics.Fix
comfy_kitchen/__init__.py: Replace the hardcoded string withimportlib.metadata.version(), which reads from the package metadata set bypyproject.toml— the single source of truth. Includes aPackageNotFoundErrorfallback for editable/dev installs.dlpack_bindings.cpp: Removed the hardcodedm.attr("__version__") = "0.1.0"from the C++ nanobind module. The Python-level__version__is the canonical source, and nobody accesses_C.__version__directly.This is the recommended approach for single-sourcing the package version in modern Python packaging.
Generated with Claude Code