Skip to content

Fix __version__ to read from package metadata instead of hardcoded string#30

Open
davidmoserai wants to merge 1 commit intoComfy-Org:mainfrom
davidmoserai:fix/version-from-metadata
Open

Fix __version__ to read from package metadata instead of hardcoded string#30
davidmoserai wants to merge 1 commit intoComfy-Org:mainfrom
davidmoserai:fix/version-from-metadata

Conversation

@davidmoserai
Copy link

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:

# comfy_kitchen/__init__.py (line 19)
__version__ = "0.1.0"
// comfy_kitchen/backends/cuda/dlpack_bindings.cpp (line 557)
m.attr("__version__") = "0.1.0";

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.0 at 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 that pip show comfy-kitchen correctly reported 0.2.7 all along. The __version__ attribute was simply wrong.

The mismatch between importlib.metadata.version("comfy-kitchen") (correct: 0.2.7) and comfy_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 with importlib.metadata.version(), which reads from the package metadata set by pyproject.toml — the single source of truth. Includes a PackageNotFoundError fallback for editable/dev installs.

# Before
__version__ = "0.1.0"

# After
try:
    from importlib.metadata import version, PackageNotFoundError
    __version__ = version("comfy-kitchen")
except PackageNotFoundError:
    __version__ = "0.0.0"  # Fallback for editable/dev installs

dlpack_bindings.cpp: Removed the hardcoded m.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

…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant