Files
malkuthro-ComfyUI-Koolook/forks
malkuthroandClaude Opus 4.7 f57ea38b71 feat(EasyResize): rename to EasyResize_Koolook + proper KJ Nodes attribution (#35)
Resolves the genuine `EasyResize` node-ID collision with
`ComfyUI-EasyFilePaths` (orange-triangle warning #8 in
ComfyUI-Manager). Both packs were registering the bare class name
`EasyResize` — load order determined which one a user actually got.

Changes:

- k_easy_resize.py:
  - Add SPDX-License-Identifier: GPL-3.0-or-later header.
  - Add proper attribution block crediting kijai/ComfyUI-KJNodes
    (Resize Image V2, GPL-3.0) as the original interface inspiration,
    with a per-feature list of how the Koolook implementation
    materially extended the surface (aspect-ratio parser,
    keep_proportion modes, mask + composed outputs, device selection,
    target/original W/H reporting, color-panel passthrough).
  - Register both `EasyResize_Koolook` (canonical, new) AND
    `EasyResize` (deprecated alias) IDs pointing at the same class.
    Saved workflows using the legacy `EasyResize` ID continue to load
    and run; new workflows pick `EasyResize_Koolook` from the search
    and avoid the conflict.
  - Display name on legacy alias reads `Easy Resize (deprecated, use
    'Easy Resize (Koolook)')` to nudge users to switch.

- forks/THIRD_PARTY.md: full attribution entry for KJ Nodes (was
  missing — manifest had it as `license: "unknown"` /
  `sync_state: "needs-upstream-reference"`). License verified as
  GPL-3.0 against upstream `LICENSE` file (same as our pack — no
  relicense pressure).

- forks/forks_manifest.yaml: KJ Nodes entry upgraded from
  `license: "unknown"` to `license: "GPL-3.0"` +
  `license_verified_at`, `status: "inspired_reimplementation"` (more
  accurate than `modified`), and the two exposed_node_ids are now
  recorded explicitly.

- README.md: node table, category list, "Easy Resize" section, and
  Wan-related descriptions all updated to use the new canonical
  `EasyResize_Koolook` ID and display name.

- pyproject.toml: 0.1.5 -> 0.1.6.
- CHANGELOG.md: [0.1.6] entry covering the rename + attribution work.

Follows the node-versioning rules from the `node-versioning` discussion
in PR review: rename via alias, never break saved workflows, document
the deprecation in CHANGELOG.

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-03 23:09:04 +02:00
..

Forks Workflow

This folder is the single source for all fork tracking metadata inside MAIN.

Purpose

  • Keep modified forked code in MAIN under versioned paths (for GitHub tracking).
  • Keep raw external checkouts outside MAIN under ../ComfyUI-Forks (for upstream reference/sync).
  • Keep all fork metadata in one place:
    • forks/forks_manifest.yaml
    • forks/THIRD_PARTY.md

Folder Layout in MAIN

  • forks/radiance_koolook/__init__.py -> package entrypoint used by root __init__.py
  • forks/radiance_koolook/versions/v1_0_1/ -> local modified node sources
  • forks/radiance_koolook/versions/<version>/UPSTREAM_PIN.yaml -> exact upstream parity pin

External Folder Naming (outside MAIN)

Root: ../ComfyUI-Forks

  • Pinned baseline checkout:
    • radiance-v1.0.1-koolook
  • Rolling upstream checkout:
    • radiance-main-upstream

These names are referenced from forks/forks_manifest.yaml.

Referencing System

For each fork entry in forks/forks_manifest.yaml:

  • source_repo = canonical upstream URL
  • source_ref = release/tag (or baseline descriptor)
  • pinned_commit = exact reproducible commit hash
  • external_checkout.relative_path_from_forks_root = pinned raw reference folder
  • external_checkout.upstream_tracking_path_from_forks_root = rolling upstream folder
  • local_paths = files tracked in MAIN

Tagging Policy (from now on)

  • MAIN repo tags use SemVer: vMAJOR.MINOR.PATCH.
  • Local fork version folders use underscore variant of the same version:
    • v1_0_1, v2_3_3, etc.
  • Node mapping namespace suffixes must match folder versions:
    • __koolook_v1_0_1, __koolook_v2_3_3, etc.
  • Keep source_ref + pinned_commit in forks/forks_manifest.yaml and UPSTREAM_PIN.yaml.

Upgrade Flow Example (Radiance)

  1. Compare current local version (forks/radiance_koolook/versions/v1_0_1) with pinned raw baseline (../ComfyUI-Forks/radiance-v1.0.1-koolook).
  2. Pull latest upstream in ../ComfyUI-Forks/radiance-main-upstream.
  3. Create a new local version folder in MAIN, e.g. forks/radiance_koolook/versions/v2_3_3.
  4. Port/validate modifications.
  5. Namespace node IDs for that version.
  6. Add new entry/update metadata in forks/forks_manifest.yaml.

Rule of Thumb

  • If it is modified production code -> keep in MAIN under forks/.../versions/...
  • If it is raw upstream reference -> keep outside MAIN under ../ComfyUI-Forks