Editable install behavior differs between project and dynamic dependencies

[Imer45]

I noticed that when I have my local dependencies under [project] with develop = true under [tool.poetry.dependencies], Poetry does not install indirect dependencies as editable.

However, if I have dependencies marked as dynamic, and all my dependencies defined under [tool.poetry.dependencies] with local ones marked as develop = true, then indirect dependencies are installed as editable.

Is this expected behavior?

[dosubot[bot]]

Yes, this is expected behavior in Poetry. When you specify dependencies in the [project] section (PEP 621), only direct dependencies marked as editable (via develop = true in [tool.poetry.dependencies]) are installed as editable. Indirect dependencies (dependencies of dependencies) are not installed as editable, even if they are marked with develop = true in their own [tool.poetry.dependencies] section. This is because [project.dependencies] is used for build metadata, and [tool.poetry.dependencies] only enriches it for locking, not for installation mode propagation to transitive dependencies.

If you want indirect dependencies to be installed as editable, you need to declare [project.dependencies] as dynamic and define all dependencies in [tool.poetry.dependencies] with develop = true. In this setup, Poetry treats all dependencies (direct and indirect) according to the develop flag, so both are installed as editable. This behavior is documented and considered by maintainers to be by design. For more details, see the dependency specification docs and maintainer comments on expected behavior.

Written by @dosu, approved by abn

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Muguett-DBY]

I can't tell from the docs whether this difference is intentional, but the current source suggests a possible explanation for local Poetry path dependencies:

• When Poetry inspects a directory dependency, PackageInfo.to_package() copies the child project's requires. requires uses the dependency group's dependencies.
• With non-empty [project].dependencies, that property returns the PEP 508 entries; in legacy mode it returns the [tool.poetry.dependencies] entries. The separate dependencies_for_locking property applies Poetry-specific enrichment. Root resolution uses all_requires, which reads that enriched list.

That could explain why a child dependency's develop = true survives in the dynamic case but not the static case. It doesn't establish what should happen in every project or whether maintainers consider it intended.

I checked the selection logic with Codex using the current DependencyGroup class and simulated dependency objects; I haven't run your exact three-project installation. If you can share your Poetry version, a minimal A → B → C set of dependency declarations, and the develop and source entries for C in the two lock files, those would help confirm whether the same path applies here.