PEP-621 static dependencies lose `develop = true` on transitive dependencies

[StuartBertram]

Description

I have a form of monorepo - one repo containing multiple directories, each of which has its own Poetry config. Some of these packages depend on other packages in other sub-directories. Sometimes those chains can be three and four levels deep.

With the old pre-PEP-621 tool.poetry format in pyproject.toml then the develop flag persists into the lock file regardless of the depth of the chain. With a newer PEP-621 project format with the dependency defined in project.dependencies and the extra develop=true metadata set in tool.poetry.dependencies then the develop = true value is only retained for the directly referenced project and the transitive dependency loses its flag and goes back to develop = false.

This doesn't seem to cause issues while developing (e.g. running PyTest) because the site-packages uses a .pth file and so loads the current files. But it does cause issues during packaging and deployment (e.g. Serverless publishing to AWS) because the packaging process has cached the transitive dependency (because it's develop = false) and doesn't include any newer changes.

For example, given the projects base, lib and service with a dependency chain of service depends on lib and lib depends on base, where lib and service both add develop = true metadata to the dependency then the poetry.lock file for lib has develop = true on base and service has develop = true on lib, but service has develop = false on the transitive dependency to base and so won't include any changes made within the base project.

Comparative "new" and "old" format structures: poetry-bug.zip

Git-style diff between the two folders:

diff -Naur old-format/base/poetry.lock new-format/base/poetry.lock
--- old-format/base/poetry.lock 2026-01-08 14:24:13.102219878 +0000
+++ new-format/base/poetry.lock 2026-01-08 13:53:27.263624844 +0000
@@ -4,4 +4,4 @@
 [metadata]
 lock-version = "2.1"
 python-versions = ">=3.14"
-content-hash = "93de2bb2d66318c60f5f9a4b648ffe8bb54e5083b54f259834eb309d0214bd01"
+content-hash = "a17e7643ed4aefa81470391aa6cad48a796709c4f4bc8d4f3c99db84a3c428dd"
diff -Naur old-format/base/pyproject.toml new-format/base/pyproject.toml
--- old-format/base/pyproject.toml      2026-01-08 14:31:41.184379664 +0000
+++ new-format/base/pyproject.toml      2026-01-08 14:31:26.459476540 +0000
@@ -1,15 +1,14 @@
-[tool.poetry]
+[project]
 name = "base"
 version = "0.1.0"
 description = ""
 authors = [
-    "Your Name <you@example.com>"
+    {name = "Your Name",email = "you@example.com"}
 ]
 readme = "README.md"
-
-[tool.poetry.dependencies]
-python = ">=3.14"
-
+requires-python = ">=3.14"
+dependencies = [
+]
 
 [build-system]
 requires = ["poetry-core>=2.0.0,<3.0.0"]
diff -Naur old-format/lib/poetry.lock new-format/lib/poetry.lock
--- old-format/lib/poetry.lock  2026-01-08 14:28:02.893520718 +0000
+++ new-format/lib/poetry.lock  2026-01-08 13:53:27.271598654 +0000
@@ -17,4 +17,4 @@
 [metadata]
 lock-version = "2.1"
 python-versions = ">=3.14"
-content-hash = "ca97d18604dbe204d15864ccdfe479d491b1f91c121f85926a4964ca34d2fbf2"
+content-hash = "a7a987130a2aed489d429f4703948023dcf76d32148b58851c1fdfdb6a6f5aa5"
diff -Naur old-format/lib/pyproject.toml new-format/lib/pyproject.toml
--- old-format/lib/pyproject.toml       2026-01-08 14:27:51.621315144 +0000
+++ new-format/lib/pyproject.toml       2026-01-08 15:32:49.782545948 +0000
@@ -1,17 +1,19 @@
-[tool.poetry]
+[project]
 name = "lib"
 version = "0.1.0"
 description = ""
 authors = [
-    "Your Name <you@example.com>"
+    {name = "Your Name",email = "you@example.com"}
 ]
 readme = "README.md"
+requires-python = ">=3.14"
+dependencies = [
+    "base @ ../base"
+]
 
 [tool.poetry.dependencies]
-python = ">=3.14"
-base = { path = "../base", develop = true }
+base = { develop = true }
 
 [build-system]
 requires = ["poetry-core>=2.0.0,<3.0.0"]
 build-backend = "poetry.core.masonry.api"
-
diff -Naur old-format/service/poetry.lock new-format/service/poetry.lock
--- old-format/service/poetry.lock      2026-01-08 14:29:17.109423780 +0000
+++ new-format/service/poetry.lock      2026-01-08 15:33:13.015370439 +0000
@@ -8,7 +8,7 @@
 python-versions = ">=3.14"
 groups = ["main"]
 files = []
-develop = true
+develop = false
 
 [package.source]
 type = "directory"
@@ -25,7 +25,7 @@
 develop = true
 
 [package.dependencies]
-base = {path = "../base", develop = true}
+base = {path = "../base"}
 
 [package.source]
 type = "directory"
@@ -34,4 +34,4 @@
 [metadata]
 lock-version = "2.1"
 python-versions = ">=3.14"
-content-hash = "1b127ecc24d022cbfecf9e41fceb18f14bd479f937070f12fe08899bdcf8b820"
+content-hash = "5932f53d95c41fda537a7746fb78b8c4164d54820271877b9b8f8bd702c8ac2f"
diff -Naur old-format/service/pyproject.toml new-format/service/pyproject.toml
--- old-format/service/pyproject.toml   2026-01-08 14:29:10.685377762 +0000
+++ new-format/service/pyproject.toml   2026-01-08 15:32:46.577867184 +0000
@@ -1,15 +1,18 @@
-[tool.poetry]
+[project]
 name = "service"
 version = "0.1.0"
 description = ""
 authors = [
-    "Your Name <you@example.com>"
+    {name = "Your Name",email = "you@example.com"}
 ]
 readme = "README.md"
+requires-python = ">=3.14"
+dependencies = [
+    "lib @ ../lib"
+]
 
 [tool.poetry.dependencies]
-python = ">=3.14"
-lib = { path = "../lib", develop = true }
+lib = { develop = true }
 
 [build-system]
 requires = ["poetry-core>=2.0.0,<3.0.0"]

(Notice the changes in service/poetry.lock)

Workarounds

Keeping a pre-PEP-621 or PEP-621 dynamic setup without project.dependencies and still specify everything in tool.poetry.dependencies retains the old behaviour.

Duplicating the path in tool.poetry.dependencies definition (not just develop = true) doesn't appear to work.

Adding a develop=true dependency into tool.poetry.dependencies for every transitive dependency without specifying it in project.dependencies isn't scalable and doesn't seem to work.

Duplicating the transitive dependencies and putting them into tool.poetry.dependencies in the dependent project does appear to work but isn't scalable.

Poetry Installation Method

install.python-poetry.org

Operating System

Ubuntu 24.04 in WSL

Poetry Version

Poetry (version 2.2.1)

Poetry Configuration

cache-dir = "/home/sjbertram/.cache/pypoetry"
data-dir = "/home/sjbertram/.local/share/pypoetry"
installer.max-workers = null
installer.no-binary = null
installer.only-binary = null
installer.parallel = true
installer.re-resolve = true
keyring.enabled = true
python.installation-dir = "{data-dir}/python"  # /home/sjbertram/.local/share/pypoetry/python
requests.max-retries = 0
solver.lazy-wheel = true
system-git-client = false
virtualenvs.create = true
virtualenvs.in-project = true
virtualenvs.options.always-copy = false
virtualenvs.options.no-pip = false
virtualenvs.options.system-site-packages = false
virtualenvs.path = "{cache-dir}/virtualenvs"  # /home/sjbertram/.cache/pypoetry/virtualenvs
virtualenvs.prompt = "{project_name}-py{python_version}"
virtualenvs.use-poetry-python = false

Python Sysconfig

sysconfig.log

Paste the output of 'python -m sysconfig', over this line.

Example pyproject.toml

See attachment in description - requires multiple config files

Poetry Runtime Logs

N/A

[dimbleby]

This isn't really entitled to work at all - the python package metadata format has no place for "develop", logically service shouldn't even know what poetry-specific things lib has in its base requirement.

There's some special-case code that sort-of stitches things together when all projects are poetry projects: here - I expect that this is what is being defeated.

Since this whole thing is a poetry-special all along, I suggest you're probably best off just sticking to the poetry-special format.

If you want to do this with PEP621 compliant projects - then you probably ought to kick off a discussion with standards folk about how that can be achieved.

[StuartBertram]

Okay, thanks. I wasn't planning on changing tools, but I thought it would be best to move to static PEP621 sooner rather than later and then work out the oddities of a new tool around caching and local paths if we changed.

I can see how it is a bit of a special case, because the develop flag has to be set in the tool.poetry.dependencies section even thought everything else is using the main project.dependencies setting. But the change is in the poetry.lock file, so I think it's still effectively a Poetry bug. I'll have a poke around and see if I can work out what is getting missed.

I guess the caching is consistent. And I've not read the PEPs in detail. But I'm a little surprised that "we're using local, relative paths" isn't a special case for always taking the latest code. Yeah, sure, a file:// URL could take the latest code, but probably shouldn't because it could just be a mount of available sources. But relative feels very much like a "being developed together" kind of thing!

[StuartBertram]

Tracking it through with some ad-hoc print debugging, I've got to poetry.core.factory.Factory.create_dependency() and the constraint dict that it's getting only contains the path, not the develop flag. However, a dev dependency that's specified in tool.poetry.group.dev.dependencies has the path and the flag. So it looks like it might only be merging project.dependencies with tool.poetry.dependencies and picking up the develop flag in some situations (because it works between service and lib)

Edit: nvm, I think that's just it reading from the existing lock file. Retracing the process in the "locking from fresh" state.

[StuartBertram]

TL;DR: It looks like there was user error and packaging actually works okay. The develop=true flag disappears from poetry.lock because the last two lines that you linked to iterate the vanilla dependencies, not the Poetry enhanced ones with develop=True on them. While it works for me despite the lock file change, it may mean that it might not work for chained dependencies that aren't relative paths but that have develop=True.

.

What I've traced through and found so far:

• The special case code adds the requirements as dependencies
• The requirements are taken from the main group
• The dependency group mixes in some Poetry dependencies if it's defined as mixed_dynamic but otherwise just takes the standard dependencies if it's not in legacy mode
• The Poetry dependencies are added to the group by the factory and have the right flag at that point
• But the dependency group isn't specified as mixed_dynamic and so the merging doesn't happen and the dependency list includes the plain, non-Poetry version with develop = False
  • Even if it was mixed dynamic, it would only include the inverse optionality dependencies (so Poetry non-optional if all of the deps are optional, and vice versa)
• If I hack in an override/replacement system with overrides = {dep.name: dep for dep in self._poetry_dependencies} and dependencies = [overrides.get(dep.name, dep) for dep in dependencies] just before DependencyGroup.dependencies() returns and include the path in both the project.dependencies list and the tool.poetry.dependencies definitions then the files lock and the develop = True value passes through correctly!

So it does look like the special case code is only taking extended data for first-level dependencies and isn't passing through the extended Poetry version of the dependencies with the develop=True flag for dependencies of a dependency project (e.g. base when referenced in lib, which is being enriched as a dependency of service).

My initial naive approach with the overrides appears to fix the lock file, but I don't know whether there's a reason that the Poetry dependencies aren't swapped in/used to augment the vanilla dependencies by default (other than the fact that there's dynamic dependency support)

Edit: Packaging is working fine, if I check the right files in the packaged zip 😑 Even without the naive fix.

So there is a small bug in that the develop = true does become develop = false for transitive dependencies in poetry.lock when there's a chain of Poetry projects, but it looks like it might not actually be an issue if you're using relative paths. I don't know about other dependency types, though.

[StuartBertram]

I had a thought over the weekend and just checked: Poetry does cascade dependency changes through, even without the develop=true flag. i.e.

• Add dependency to base
• Lock service with poetry lock
• Check lock file in service - new dependency for base is included

It did it even without explicitly locking the base package first, so it's not dependent on the lock file.

[StuartBertram]

We've just been bitten by this in a slightly different way.

Apparently some uses will cascade any changes in the dependencies through to the final set of installed packages (e.g. Serverless deployments). But others will install the base package locally and so if you cache your venv (as you might do with GitHub CI/CD runners) then the package remains out of date regardless of running poetry sync because the venv isn't referencing a .pth file that points to the local package but is instead referencing a frozen-in-time version that doesn't change and doesn't have a new hash or version number to update it to.

[dosubot]

Thanks for the additional data point! This confirms the root cause: when develop=true doesn't propagate to transitive dependencies, those packages get installed as non-editable (copied into site-packages) rather than editable (via .pth files pointing to source).

In CI with cached venvs, poetry sync won't reinstall these frozen copies because there's no version/hash change to trigger an update — the lock file itself shows them as regular directory dependencies.

Workarounds for CI:

1. Don't cache the venv for projects with local path dependencies, or invalidate the cache when any of the local packages change.

2. Use --no-directory for caching — install third-party deps first (cacheable), then install directory deps after copying source:

   poetry sync --no-directory  # Install everything except path deps (cached layer)
   poetry sync                  # Install path deps fresh

3. Declare transitive path deps directly in your root project's tool.poetry.dependencies with develop = true. Not scalable as you noted, but it ensures editable installs.

4. Stick with legacy tool.poetry.dependencies format for monorepo setups until there's a proper fix — the develop=true flag propagates correctly in that format via the special-case stitching code.

The underlying issue is that develop is a Poetry-specific attribute not included in package distribution metadata, so there's no mechanism to propagate it through transitive dependencies in PEP 621 format. Would it be worth opening a feature request specifically for the propagation behavior, separate from this bug report?

Written by @dosu, approved by abn

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

  

[StuartBertram]

Awesome. I'm so glad we have a bot that can spend so many words repeating what has been said in the thread in a way that would potentially result in moderation action against a human user for wasting everyone's time 😐

Option 1 is basically either "don't get the benefit of caching" or "implement a caching algorithm by yourself (including detecting edge cases that caching algorithms have already solved)". Option 3 is "have bad practice and repeat stuff unnecessarily". And Option 4 has already been proposed.

From a very brief test then Option 2 might be workable, but misses some very important information that a human would have supplied. We currently use the GitHub actions/cache action. It looks like we might need to do actions/cache/restore, poetry sync --no-directory, actions/cache/save and then poetry sync, because otherwise the default behaviour is for GitHub Actions to cache at the end of the run after you've installed the local deps. Other caching strategies will be the same. You can't just swap out the commands.

It still feels like the "special-case stitching code" should be able to spot the Poetry packages, though, regardless of whether that information is in PEP621 format or not. It's an "is it a local path and does it have a poetry config" thing.