Summary
The modules/hello/ sample module that sm new (in simple_module_cli==0.0.8) now generates pins its framework deps to a 1.x range, but the framework is at 0.0.x. uv sync fails immediately on a fresh scaffold with an unsatisfiable workspace.
Reproduction
$ uvx --from simple_module_cli sm new my-app --db sqlite --preset standard -y --no-install
$ cd my-app && cp .env.example .env
$ make install
uv sync
Using CPython 3.12.10
Creating virtual environment at: .venv
× No solution found when resolving dependencies:
╰─▶ Because simple-module-chat depends on simple-module-hosting==0.0.8
and simple-module-hello depends on simple-module-hosting>=1.0,<2.0,
we can conclude that simple-module-chat and simple-module-hello are
incompatible.
And because your workspace requires simple-module-chat and
simple-module-hello[dev], we can conclude that your workspace's requirements are unsatisfiable.make: *** [install] Error 1
Root cause
modules/hello/pyproject.toml (generated):
[project]
name = "simple_module_hello"...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",
]
But on PyPI, simple_module_core (and friends) are at 0.0.8. simple_module_test is at 0.0.8 too. The host's own pyproject.toml correctly pins ==0.0.8. So the host says "I want 0.0.8" and hello says "I want 1.x" — uv can't satisfy both.
simple_module_test>=0.1,<1.0 is also unsatisfiable: 0.0.8 is not >=0.1.
The framework's own modules in modules/auth/pyproject.toml (in the source tree) use simple_module_core==0.0.7 style exact pins, so the working pattern exists — the scaffold template just used the wrong shape.
Suggested fix
The scaffold template for modules/<name>/pyproject.toml should pin to a range that includes the framework's current published version. Two cleanly-shaped options:
Match the host scaffold's exact-pin style. Have sm new substitute its own version in for both the host pins AND the sample module pins:
dependencies = [
"simple_module_core=={cli_version}",
"simple_module_db=={cli_version}",
"simple_module_hosting=={cli_version}",
"pydantic-settings>=2.0",
"sqlalchemy>=2.0",
]Use [tool.uv.sources] workspace pins for the sample. Since the host's pyproject.toml already does this for simple_module_hello:
[tool.uv.sources.simple_module_hello]
workspace = true
The sample module itself could declare loose ranges (>=0.0.1) and rely on the host's exact pin to constrain the resolution.
Either way, the dev dep should also be fixed:
- "simple_module_test>=0.1,<1.0",+ "simple_module_test>=0.0.8,<0.1",
Suggested test
Add a CLI regression that runs sm new into a tmpdir and runs uv sync against it. Should pass without manual intervention.
Workaround
Edit modules/hello/pyproject.toml:
dependencies = [
- "simple_module_core>=1.0,<2.0",- "simple_module_db>=1.0,<2.0",- "simple_module_hosting>=1.0,<2.0",+ "simple_module_core>=0.0.8,<0.1",+ "simple_module_db>=0.0.8,<0.1",+ "simple_module_hosting>=0.0.8,<0.1",
...
]
...
- "simple_module_test>=0.1,<1.0",+ "simple_module_test>=0.0.8,<0.1",
Related
Environment
simple_module_cli 0.0.8simple_module_core, simple_module_db, simple_module_hosting, simple_module_test all at 0.0.8 on PyPI
Summary
The
modules/hello/sample module thatsm new(insimple_module_cli==0.0.8) now generates pins its framework deps to a 1.x range, but the framework is at 0.0.x.uv syncfails immediately on a fresh scaffold with an unsatisfiable workspace.Reproduction
Root cause
modules/hello/pyproject.toml(generated):But on PyPI,
simple_module_core(and friends) are at0.0.8.simple_module_testis at0.0.8too. The host's ownpyproject.tomlcorrectly pins==0.0.8. So the host says "I want 0.0.8" and hello says "I want 1.x" — uv can't satisfy both.simple_module_test>=0.1,<1.0is also unsatisfiable:0.0.8is not>=0.1.The framework's own modules in
modules/auth/pyproject.toml(in the source tree) usesimple_module_core==0.0.7style exact pins, so the working pattern exists — the scaffold template just used the wrong shape.Suggested fix
The scaffold template for
modules/<name>/pyproject.tomlshould pin to a range that includes the framework's current published version. Two cleanly-shaped options:Match the host scaffold's exact-pin style. Have
sm newsubstitute its own version in for both the host pins AND the sample module pins:Use
[tool.uv.sources]workspace pins for the sample. Since the host'spyproject.tomlalready does this forsimple_module_hello:The sample module itself could declare loose ranges (
>=0.0.1) and rely on the host's exact pin to constrain the resolution.Either way, the dev dep should also be fixed:
Suggested test
Add a CLI regression that runs
sm newinto a tmpdir and runsuv syncagainst it. Should pass without manual intervention.Workaround
Edit
modules/hello/pyproject.toml:Related
Environment
simple_module_cli0.0.8simple_module_core,simple_module_db,simple_module_hosting,simple_module_testall at 0.0.8 on PyPI