poetry: 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 <cahurst@cisco.com>"]

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

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 30
Comments: 16 (2 by maintainers)

Most upvoted comments

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.

+16

al-muammar on May 1, 2020

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.

wakemaster39 on Apr 20, 2020

i agree with @fredrikaverpil , as i have a scenario currently needs this behavior. with respect to pyproject.toml my expected behavior would be:

[tool.poetry.dependencies]
...
private-repo-latest = {git = "ssh://git@bitbucket.org/<my-user>/<my-repo>.git", branch = "specific-branch"}
private-repo-specific-from-branch = {git = "ssh://git@bitbucket.org/<my-user>/<my-repo>.git", rev = "specific-branch"}
private-repo-specific-from-tag = {git = "ssh://git@bitbucket.org/<my-user>/<my-repo>.git", tag = "1.2.3"}

upon poetry install: private-repo-lastest - would be latest and greatest from specific-branch private-repo-specific-from-branch - would be a specific commit specified in poetry.lock file (the commit which was latest when we installed the package, or an updated commit if someone re-synced poetry.lock with poetry update or poetry lock) private-repo-specific-from-tag - would always be a specified commit marked with that tag (obviously…). this is also the behavior if specified rev with a concrete commit hash.

i believe that this will cover all needed behaviors with the most simplistic and intuitive syntax. would also be happy to work on that with a PR if core-contributors agree with that approach!

hagaika on Nov 19, 2020

@mprudek this issue is 100% still a problem in the 1.1.x branch. My changes got merged into master (1.2.x) and never got the back port.

wakemaster39 on May 3, 2022

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.

+1 on this.

Although it may be a corner case, I have a scenario where I need poetry to install the latest and greatest from a git master on every poetry install. But then this behavior vs the one locked to a commit should have different declarations in pyproject.toml, and should also be supported from the CLI.

You can argue that “you should not do this” and so on, but it serves a real world scenario. I can agree that this behavior should perhaps not be the default though. So whatever happens, at least give the option to be able to fetch the latest and greatest and not remove this current functionality.

fredrikaverpil on Jul 3, 2020