Cannot use the same package in develop mode for dev and non-develop mode for non-dev

[jazzblue]

• [ x] I am on the latest Poetry version.
• [ x] 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: MacOS
• Poetry version: 1.0.10
• Link of a Gist with the contents of your pyproject.toml file:

Issue

This is my poproject.toml

[tool.poetry.dependencies]
python = "^3.7"
my-lib = {path = "../lib/my-lib", develop = false}
pandas = "^1.1.0"

[tool.poetry.dev-dependencies]
pylint = "^2.5.3"
pytest = "^6.0.1"
black = {version = "^19.10b0", allow-prereleases = true}
my-lib = {path = "../lib/my-lib", develop = true}

1. run: poetry install
   The contents of poetry.lock will be:

...
[[package]]
category = "main"
description = "My lib"
develop = true
name = "my-lib"
optional = false
python-versions = ">= 3.6"
version = "0.0.0"
...

2. Now run: poetry install --no-dev
   The contents of poetry.lock will be unchanged:

...
[[package]]
category = "main"
description = "My lib"
develop = true
name = "my-lib"
optional = false
python-versions = ">= 3.6"
version = "0.0.0"
...

I would expect develop = false after the last command. This is needed to be able to debug with my-lib in dev mode and install the package in non-dev mode for deployment. It seems like this would be the expected behavior which apparently is not working.

Thanks.

[TBBle]

What happens if you install with --no-dev first, does it install in develop mode or not?

i.e. is this a bug that the dependency is in both lists, and gets merged or is it a bug that it sees the dependency is present, but not that its develop value is wrong?

Edit: Someone replicated this in #1168 (comment), and the apparent answer is that it always obeys the details of the dev-dependency.

It's visible earlier in the thread that if the requirements conflict between dev and non-dev, Poetry will reject the build resolution, which seems reasonable.

So my guess is that Poetry's approach is to just merge all the dev-dependencies into the non-dev dependencies, with the develop flag not considered for conflict-resolution and hence taking dev-dependency's value as the result, and then building the lock file, so that --no-dev does not affect the lock file.

Since the lockfile contains whether the dependency was 'develop' or not, I suspect this will be not simple to fix, since that would require tracking two versions of the dependency, and choosing the right one (even though they're the same apart from develop) based on --no-dev's presence or absence.

[TBBle]

Thinking about this, does it even make sense for path-dependencies to appear in the lock file? Unlike a git dependency (which probably has very similar issues...) you can't feasibly lock a path-dependency to a particular version, the best you can do is validate at install-time that it matches the version specification, if you're using one.

A git dependency can capture the specific commit at lock-time, but I'm not sure if Poetry does this.

[DanCardin]

You can't lock a path dependency to a version, but presumably it needs to exist in the lockfile in order for the transitive dependencies to be included.

For the original issue, I've hit this as well.

You ultimately need the pyproject.toml (not just the poetry.lock to perform an installation in the first place. So it would seem to me (naively without knowing what's easily possible and what's not), that without changing resolution at all, the installation-time logic could look at pyproject.toml refererence where applicable and choose the develop value depending on the selected mode.

Alternatively, this somewhat seems to be analogous to installation-time constraints like python_version. So a group-specific constraint mapping the selection of the develop value. Although this seems like it would be more involved and change the lockfile ultimately.

[finswimmer]

Please have a look into this discussion: https://github.com/orgs/python-poetry/discussions/3646

[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.