Repository navigation
Changing develop option is not reflected #3085
Description
- 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 (
-vvvoption).
- 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}
...
Activity
ginty commentedon Oct 5, 2020
I came here to say the same thing.
I expect that with
develop=truea 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 on1.1.0the dependency is copied into the virtualenv so that updates to the original source have no effect, even withdevelop=true.abn commentedon Oct 5, 2020
@ginty that is what happens. The dependency is not copied, but installed as an editable dependency. However, since we do not use the
egg-linkhack,pipwill 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 dopoetry run pip uninstall barfirst. The previous installation would have usedegg-links, when doing an update withdevelop=truenothing will change, since it is what it was defaulting to previously.tamuhey commentedon Oct 6, 2020
No. The venv is created by poetry v1.1.1
Ok, I'll deal with it that way for now.
tamuhey commentedon Oct 6, 2020
One question: Changing the default value for
developbreaks backwards compatibility (e.g. in case of using symlink). Why this change is introduced inv1.1?ginty commentedon Oct 6, 2020
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 commentedon Dec 7, 2021
I am still seeing this issue on poetry 1.1.12. To be explicit:
pyproject.tomlhasdep = {path = "/path/to/dep"}poetry update/path/to/depis copied into the venv, as expectedpyproject.tomlto havedep = {path = "/path/to/dep", develop=true}poetry updatedepin the venv being replaced bydep.pthfile, 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 updatehas done the right thing -- it's a shame to spend time cautiously deleting venvs just in case.kkuriata commentedon Apr 11, 2022
Yeah. I can confirm that it is really annoying. It's hard to develop anything when you have to
poetry updateafter changes... And it takes much time to do that.smcoll commentedon Nov 7, 2022
Using 1.2.1 i was able to get an editable install working by updating to
develop = truein the lockfile as well, then deleting the virtual environment (i'm using local .venv dir) before apoetry install. This method is creating a.pthfile for each dependency insite-packages.Of course, the issue description is still valid.
neersighted commentedon Nov 8, 2022
Resolved in #6843.
github-actions commentedon Mar 1, 2024
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.