[smpy][create-module] generated module pins simple_module_* at >=1.0,<2.0 — unsatisfiable on PyPI, so 'uv add ./modules/<name>' fails

[antosubash]

Summary

A module created with smpy create-module cannot be added to a same-version app with uv add ./modules/<name> — uv resolution fails because the generated pyproject.toml pins the framework packages at forward-looking ranges that don't exist on PyPI:

• dependencies: simple_module_core>=1.0,<2.0, simple_module_db>=1.0,<2.0, simple_module_hosting>=1.0,<2.0
• [project.optional-dependencies].dev: simple_module_test>=0.1,<1.0

The published distributions are all 0.0.17 (the framework API version is 1.0.0, but the distribution version is 0.0.x). 0.0.17 satisfies neither >=1.0,<2.0 nor >=0.1,<1.0, so the workspace is unsatisfiable.

smpy new avoids this for its bundled sample module by rewriting the pins to ==<framework_version> (app_project._pin_or_keep), but smpy create-module emits the raw ranges, so the documented "create-module then uv add" flow is broken on the current release.

Environment

• simple_module_cli (smpy): 0.0.17 (PyPI)
• Published simple_module_* distributions: 0.0.17
• uv: 0.11.7, Python: 3.12.3, OS: Linux (Ubuntu)

Minimal reproduction

uv tool install simple_module_cli==0.0.17
smpy new demo --preset standard --db sqlite --no-tenancy --yes
cd demo
smpy create-module orders --dest modules/orders
# register it on the host:
# host/pyproject.toml: add "simple_module_orders" to dependencies
# add [tool.uv.sources] simple_module_orders = { workspace = true }
uv sync --all-packages

Expected vs actual

• Expected: a freshly created module is uv add-able into the app that created it, with no manual pyproject edits.
• Actual: uv sync fails:

… your workspace requires simple-module-orders[dev] and demo:dev,
we can conclude that your workspace's requirements are unsatisfiable.
…
Because simple-module-orders depends on simple-module-core>=1.0,<2.0 and
no versions of simple-module-core matching >=1.0,<2.0 exist, …

(The [dev] extra fails first on simple_module_test>=0.1,<1.0; removing it surfaces the same problem on simple_module_core>=1.0,<2.0.)

Root cause

framework/cli/simple_module_cli/templates/module/pyproject.toml ships forward-looking ranges. The new-app generator post-processes the sample module's pins (_pin_or_keep → ==<version>), but create-module writes the template verbatim. Distribution versions are 0.0.x, so the ranges resolve to nothing.

Suggested fix

Have create-module pin the framework deps (and the simple_module_test dev extra) to the installed framework version — i.e. apply the same _pin_or_keep rewrite the new-app scaffold uses — or special-case the 0.0.x-vs-1.0 API-vs-dist version gap.

Impact + workaround

Blocks the documented module-authoring quickstart on the current release. Workaround applied while building: edited modules/<name>/pyproject.toml to pin simple_module_core/db/hosting/auth==0.0.17 and the dev extra simple_module_test==0.0.17; uv sync then resolves.