Git Dependencies do not respect lock file

• 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: macOS, RedHat 7.6, Fedora 31

• Poetry version: 1.0.5

[tool.poetry]
name = "test2"
version = "0.1.0"
description = ""
authors = ["Cameron Hurst <[e-mail]>"]

[tool.poetry.dependencies]
python = "^3.8"
test-abc = {git="git@xxxx:xxxxxxxx/test-abc.git"}

[tool.poetry.dev-dependencies]

[build-system]
requires = ["poetry>=0.12"]
build-backend = "poetry.masonry.api"

Issue

I have created two test projects so I could verify this, simple contain no code just a git repo where one of them lives. The expectation I had, is what when I do a poetry install for the first time on my test2 repo that is shown above, a poetry lock file would be generated which contains the revision that the git should be locked against. This currently happens

[package.source]
reference = "6795f40dbe1f9a28dee1c3c5b2fae09763afa0be"
type = "git"
url = "git@xxxxx:xxxxx/test-abc.git"

I then go and push a change to test-abc and run poetry install again in test 2. My expectation here is that nothing changes and life is good. This is where I believe to be a Critical bug occurs:

Package operations: 0 installs, 1 update, 0 removals

  - Updating test-abc (0.1.0 6795f40 -> 0.1.0 a10f113)

The contents of the poetry.lock file remain unchanged, but I now have an updated dependency.

Now rev locking to that specific revision works, it is just the default does not respect the poetry.lock file defeating the purpose of the lock file here in my opinion.

There are a couple other issues I found on here which reference resolving tags and branches to specific hashes in the lock file, so it seems like the intent here is for git to install the specific hash and not latest by default.

[al-muammar]

We as well were just affected by this bug, when a breaking change happened in one of our git dependency repositories, which broke our trunk and CI didn’t catch it.
The lock file should be respected no matter what during the poetry install.

[wakemaster39]

I have done more digging and made a PR, but I have run into one problem https://github.com/python-poetry/poetry/blob/288d99739fba4425def7c567d71537ce5bd2a0f9/tests/puzzle/test_solver.py#L1276-L1309

I disagree with this unit test and the expectations it sets which has led me to file this bug but now looks like it is an intentional feature. The solver solves the problem based on the constraints it is given, but it seems like in this situation it is making assumptions about how constraints should be treated and ignored.

On an install, I would expect that the constraints of a lock file are respected no matter the condition and on an update a new set of constraints are generated and evaluated on the course of action that should be taken.

The installation process already has the update capability which generates a new lock file, putting in the new revision to lock the git repo to. But then the solver ignores that and just always updates. This seems like a bad situation and not respecting the poetry.lock file.