Pipeline imports break when easyStitch is consumed as a package #32

New issue

Closed

opened 2026-06-22 16:23:18 +00:00 by Mark · 1 comment

Mark commented

2026-06-22 16:23:18 +00:00

Owner

Bug

src/main_pipeline.py uses top-level (non-relative) imports for components
in the same package:

from intent_resolver.dom_resolver import DOMIntentResolver
from intent_resolver.stitch_intent import MachineProfile
from post_processor.physical_optimizer import PhysicalOptimizer
from raster.raster_converter import RasterToVectorConverter
from svg_annotation.semantic_analyzer import SemanticAnalyzer

These should be relative imports (or absolute imports rooted at the package
name) for the package to be importable from anywhere. As written, the pipeline
only works if you cd src && python -m main_pipeline or use the Docker image
which sets WORKDIR /app/src.

Reproduction

cd /home/b/Projects/easystitch
source .venv/bin/activate
python -c "import sys; sys.path.insert(0, 'src'); from main_pipeline import EmbroideryPipeline"
# ModuleNotFoundError: No module named 'intent_resolver'

vs.:

cd /home/b/Projects/easystitch/src
python -c "from main_pipeline import EmbroideryPipeline"
# works

Impact

The ThreadCraft HTTP wrapper (per #11) cannot import easyStitch as a
Python package; it has to manipulate sys.path to make the relative
imports resolve. That's a deploy-time footgun.
The Dockerfile masks the bug; nothing else does.
Any third-party consumer hits the same wall.

Fix

Change the 5 imports in src/main_pipeline.py to be relative or absolute-from-package:

# from intent_resolver.dom_resolver import DOMIntentResolver
# → from .intent_resolver.dom_resolver import DOMIntentResolver

Apply the same audit across the rest of src/ — any module that imports a
sibling should use relative imports. Grep for ^from [a-z_]+ import (not
^from \.) in src/main_pipeline.py, src/main.py, and the entry-point
modules.

Add a CI step that runs python -c "import easystitch" (or whatever the
package name is) from outside src/ to catch this class of bug.

Acceptance

import easystitch (or from <pkg> import EmbroideryPipeline) works from
any working directory.
A CI smoke test asserts the import.
ThreadCraft's HTTP wrapper can import easyStitch without sys.path hacks.

## Bug `src/main_pipeline.py` uses **top-level (non-relative) imports** for components in the same package: ```python from intent_resolver.dom_resolver import DOMIntentResolver from intent_resolver.stitch_intent import MachineProfile from post_processor.physical_optimizer import PhysicalOptimizer from raster.raster_converter import RasterToVectorConverter from svg_annotation.semantic_analyzer import SemanticAnalyzer ``` These should be **relative imports** (or absolute imports rooted at the package name) for the package to be importable from anywhere. As written, the pipeline only works if you `cd src && python -m main_pipeline` or use the Docker image which sets `WORKDIR /app/src`. ## Reproduction ```bash cd /home/b/Projects/easystitch source .venv/bin/activate python -c "import sys; sys.path.insert(0, 'src'); from main_pipeline import EmbroideryPipeline" # ModuleNotFoundError: No module named 'intent_resolver' ``` vs.: ```bash cd /home/b/Projects/easystitch/src python -c "from main_pipeline import EmbroideryPipeline" # works ``` ## Impact - The ThreadCraft HTTP wrapper (per #11) cannot `import` easyStitch as a Python package; it has to manipulate `sys.path` to make the relative imports resolve. That's a deploy-time footgun. - The Dockerfile masks the bug; nothing else does. - Any third-party consumer hits the same wall. ## Fix Change the 5 imports in `src/main_pipeline.py` to be relative or absolute-from-package: ```python # from intent_resolver.dom_resolver import DOMIntentResolver # → from .intent_resolver.dom_resolver import DOMIntentResolver ``` Apply the same audit across the rest of `src/` — any module that imports a sibling should use relative imports. Grep for `^from [a-z_]+ import` (not `^from \.`) in `src/main_pipeline.py`, `src/main.py`, and the entry-point modules. Add a CI step that runs `python -c "import easystitch"` (or whatever the package name is) from outside `src/` to catch this class of bug. ## Acceptance - `import easystitch` (or `from <pkg> import EmbroideryPipeline`) works from any working directory. - A CI smoke test asserts the import. - ThreadCraft's HTTP wrapper can `import` easyStitch without `sys.path` hacks.