You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I run poetry update and I have my lock file, with the commit sha of this particular branch at this particular time.
Now I force push my branch feat/branch and I try running poetry install, I have the following error:
CalledProcessError
Command '['git', '--git-dir', '.../.cache/pypoetry/virtualenvs/poetry-bug-MXzYaQCP-py3.8/src/foo/.git', '--work-tree', '.../.cache/pypoetry/virtualenvs/poetry-bug-MXzYaQCP-py3.8/src/foo', 'checkout', '99eeaa1910a597818b134319db5641cd61d27978']' returned non-zero exit status 128.
at ~/.poetry/lib/poetry/utils/_compat.py:217 in run
213│ process.wait()
214│ raise
215│ retcode = process.poll()
216│ if check and retcode:
→ 217│ raise CalledProcessError(
218│ retcode, process.args, output=stdout, stderr=stderr
219│ )
220│ finally:
221│ # None because our context manager __exit__ does not use them.
This is because the commit sha of the poetry.lock file does not exist anymore (or is not in a branch at least).
I would like this use-case to be valid, without having to run poetry update every time my branch changes. This is perhaps more of a feature request than a bug report. I understand that the current behavior is also valid. Could it be an option in the configuration not to write the commit sha in the lock file?
-vvv
option).Issue
I use poetry with a git dependency on a particular branch:
I run
poetry update
and I have my lock file, with the commit sha of this particular branch at this particular time.Now I force push my branch
feat/branch
and I try runningpoetry install
, I have the following error:This is because the commit sha of the
poetry.lock
file does not exist anymore (or is not in a branch at least).I would like this use-case to be valid, without having to run
poetry update
every time my branch changes. This is perhaps more of a feature request than a bug report. I understand that the current behavior is also valid. Could it be an option in the configuration not to write the commit sha in the lock file?This is related to this issue: #5002 AFAICT
Thank you all for the awesome work,
regards
The text was updated successfully, but these errors were encountered: