[PR #30] Fix version to read from package metadata instead of hardcoded string #90

New issue

Open

opened 2026-10-26 22:20:15 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-26 22:20:15 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/Comfy-Org/comfy-kitchen/pull/30
Author: @davidmoserai
Created: 2/22/2026
Status: 🔄 Open

Base: main ← Head: fix/version-from-metadata

📝 Commits (1)

1ce2658 Fix version to read from package metadata instead of hardcoded string

📊 Changes

2 files changed (+6 additions, -3 deletions)

View changed files

📝 comfy_kitchen/__init__.py (+6 -1)
📝 comfy_kitchen/backends/cuda/dlpack_bindings.cpp (+0 -2)

📄 Description

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

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/Comfy-Org/comfy-kitchen/pull/30 **Author:** [@davidmoserai](https://github.com/davidmoserai) **Created:** 2/22/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/version-from-metadata` --- ### 📝 Commits (1) - [`1ce2658`](https://github.com/Comfy-Org/comfy-kitchen/commit/1ce26583d5349829aa590622a420557371cc5c45) Fix __version__ to read from package metadata instead of hardcoded string ### 📊 Changes **2 files changed** (+6 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `comfy_kitchen/__init__.py` (+6 -1) 📝 `comfy_kitchen/backends/cuda/dlpack_bindings.cpp` (+0 -2) </details> ### 📄 Description ## 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: ```python # comfy_kitchen/__init__.py (line 19) __version__ = "0.1.0" ``` ```cpp // 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. ```python # 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](https://packaging.python.org/en/latest/guides/single-sourcing-package-version/#importlib-metadata) for single-sourcing the package version in modern Python packaging. --- *Generated with [Claude Code](https://claude.ai/claude-code)* --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-10-26 22:20:15 +00:00

bsakaguchi referenced this issue

2026-10-26 22:20:44 +00:00

[PR #90] [MERGED] Add optimized w4a8 with int8 codebook #136

bsakaguchi referenced this issue

2026-10-26 22:20:48 +00:00

[PR #97] [MERGED] HIP port of #90: grouped W4A8 over the INT8 GEMM #143