Changing develop option is not reflected

[tamuhey]

• I am on the latest Poetry version.
• I have searched the issues of this repo and believe that this is not a duplicate.
• If an exception occurs when executing a command, I executed it again in debug mode (-vvv option).

• OS version and name: Mac OS X 10.14.6
• Poetry version: 1.1.1
• Link of a Gist with the contents of your pyproject.toml file: https://github.com/tamuhey/poetry111_bug_mvce (not gist)

Issue

TLDR; changing develop of a dependency field and poetry update don't have any effect.

I have a project consists of two poetry project:

. --  foo/
  |     |- pyproject.toml
  |-- bar/
        |- pyproject.toml

foo depends on bar as follows:

# pyproject.toml
...
[tool.poetry.dependencies]
python = "^3.8"
bar = {path="../bar"}
...

(Full example here: https://github.com/tamuhey/poetry111_bug_mvce/blob/master/foo/pyproject.toml)

Since the editable mode is false by default from poetry v1.1, bar is copied into another directory. It's ok.

But, after changing the dependency of bar to editable (develop = true) as follows and running poetry update don't change anything, as I expected that bar is changed to editable dependency.

# pyproject.toml
...
[tool.poetry.dependencies]
python = "^3.8"
bar = {path="../bar", develop=true}
...

[ginty]

I came here to say the same thing.

I expect that with develop=true a link will be created to the given path, such that when the files are updated they are automatically reflected in the parent app.

That works fine on 1.0.10 (without develop=true) but on 1.1.0 the dependency is copied into the virtualenv so that updates to the original source have no effect, even with develop=true.

[abn]

@ginty that is what happens. The dependency is not copied, but installed as an editable dependency. However, since we do not use the egg-link hack, pip will not show it as a "develop" depenency.

@tadeoos am I correct in assuming that your scenario is an existing virtual environment created using 1.0.10? If so you will have to either re-add the dependency or re-create the virtualenvironment or do poetry run pip uninstall bar first. The previous installation would have used egg-links, when doing an update with develop=true nothing will change, since it is what it was defaulting to previously.

[tamuhey]

am I correct in assuming that your scenario is an existing virtual environment created using 1.0.10?

No. The venv is created by poetry v1.1.1

If so you will have to either re-add the dependency or re-create the virtualenvironment or do poetry run pip uninstall bar first.

Ok, I'll deal with it that way for now.

[tamuhey]

One question: Changing the default value for develop breaks backwards compatibility (e.g. in case of using symlink). Why this change is introduced in v1.1?

[ginty]

Thanks for the quick reply @abn. I don't really understand what you mean, however, as this may be going off on a tangent from the original thread I've opened #3096 for further discussion on it.

[lochsh]

I am still seeing this issue on poetry 1.1.12. To be explicit:

• pyproject.toml has dep = {path = "/path/to/dep"}
• I run poetry update
• /path/to/dep is copied into the venv, as expected
• I edit pyproject.toml to have dep = {path = "/path/to/dep", develop=true}
• I run poetry update
• Instead of the dep in the venv being replaced by dep.pth file, it is not replaced and so I do not have an editable dependency.

Issues such as this and #3958 make it hard to feel confident that poetry update has done the right thing -- it's a shame to spend time cautiously deleting venvs just in case.

[kkuriata]

Yeah. I can confirm that it is really annoying. It's hard to develop anything when you have to poetry update after changes... And it takes much time to do that.

[smcoll]

Using 1.2.1 i was able to get an editable install working by updating to develop = true in the lockfile as well, then deleting the virtual environment (i'm using local .venv dir) before a poetry install. This method is creating a .pth file for each dependency in site-packages.

Of course, the issue description is still valid.

[neersighted]

Resolved in #6843.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.