poetry local dependency in develop mode

Question

I'm trying to use poetry in a project that uses local dependencies. Specifically, I have two other poetry projects that are included as git submodules, I've added them to the top level poetry project as path dependencies.

[tool.poetry.dependencies]
python = "^3.8"
pydantic = "^1.9.0"
adp-utils = {path = "../../adp-utils", develop = false}
adp-cfw = {path = "../../adp-cfw", develop = false}

If I set my dependencies with develop = false, I can import them in my client code and all works well. However, since I'm making changes to the libraries as I develop the application, any changes to the library require me to bump the library version and run poetry update on the top level project.

When I try to set develop = true, import statements fail on the top level application. The libraries are still installed, and inspection of the site-packages folder on the venv shows that they are there.

Answer 1

I believe I just ran into the same thing and found the solution. My project is structured:

• TopLevelApp
• TLACustomLib
  • SomeExternalDependency
  • AnotherExternalDependency

Both the TopLevelApp and the TLACustomLib have their poetry.toml configurations set to in-project = true so that the dependencies are installed into a virtualenv in each respective project (following in the footsteps of OpenDoor).

TopLevelApp pyproject.toml has TLACustomLibs as a dependency similar to yours:

[tool.poetry.dependencies]
...
tlacustomlibs = {path = "../tlacustomlibs", develop = true}
...

On poetry install, Poetry will go resolve all of the dependencies of TLACustomLibs and add them to the TopLevelApp poetry.lock file - then install the dependencies directly in TopLevelApp's virtualenv so it has access to them. But subsequent additions of dependencies to the TLACustomLib project will not be propagated to the TopLevelApp. Even deleting the .venv directory and reinstalling dependencies won't fix the problem.

The fix is to, once you've installed the new dependency in TLACustomLib, go to the TopLevelApp directory and run a poetry update so that it has the chance to update the lockfile. Then it should be aware of the added sub-dependencies and happily install them in its own top-level virtualenv directory.