Poetry update hangs when prompted for ssh key passphrase

[danihodovic]

Re-opening https://github.com/python-poetry/poetry/issues/446 which was automatically closed.

I successfully added private git repository using poetry add --git ssh://git@gitlab_url/username/repository_name.git package_name. Then I ran poetry update, but it hanged forever on cloning repository (there: https://github.com/sdispater/poetry/blob/master/poetry/vcs/git.py#L99). The problem is that I have to authenticate using my ssh key for cloning repository, git asks for the passphrase, but I cannot enter it.

[gehring]

I ran into a similar issue when authenticating with https, e.g., poetry add git+https://github.com/username/my_private_repo.git. Oddly enough, running it with -vvv allowed me to run it to completion but I had to type in my login info 4 different times!

I had to type it in 1) at the start, 2) while "resolving dependencies", 3) in between "writing lock file" and "Package operations: 1 install, [...]", and 4) at the very end after the final " - Installing my_private_package ..." message.

[Izoelektro]

Confirming that this is still an issue as of Poetry version 1.1.3.

It seems as if the poetry CLI/prompt overshadows the Git one - I am assuming this because for me the poetry prompt (without verbosity) keeps flashing and at times shows the Git prompt. I have even managed to make it work simply by guessing when the Git prompt appeared and typing in my username and passphrase multiple times.

This would explain the current issue (#446) as well as #863 (which was observed to be related already). Funnily enough, they have a similar issue over at pipenv. Seeing as the CL package used by poetry is built by hand as it is, I am guessing it should not be that hard to solve this (although I am far from capable of doing it). I see why it would not be of high priority to do so however.

[abn]

It seems that it might be senisble to disable interactions for the git client and document that cases that need credentials should really use https://git-scm.com/docs/gitcredentials.

[danihodovic]

@abn Can't you forward stdin / stdout between the git subprocess to the user process when the password prompt is triggered?

[abn]

I suspect that will cause more problems than it solves. For example, when multiple operations happen in parallel. Better to keep this simple.

[danihodovic]

Usually the ssh key is prompted for once and saved in the ssh-agent.

[abn]

Yeah but the issue is when multiple processes request at the same time. I'm inclined to day that it's safer to document this and error out gracefully. Maybe even a detailed message on what to try.

[Izoelektro]

From a user standpoint, git credentials do a fairly good job of solving it. Just documenting the issue would already help quite a lot in my opinion. Simply as an idea, would command-line options to provide credentials be a possible solution? That would likely cause some 'bloat' (verbosity) in the commands however.

[Mpreyzner]

I have the same problem with resources from https not ssh. Exception with explanation why it failed would be sufficient for me.

[tector]

This is a super annoying issue :-/ I have to type my SSH Passphrase at least 6 times on each install or update...

Any update on this? I use the newest version of poetry.

[pietermarsman]

One way around this is to run ssh-add before running poetry. This will add your ssh identities and remember them until you close your terminal session.

[dimbleby]

fixed at #5880 (and duplicated by #3222)

[hummus]

It seems that it might be senisble to disable interactions for the git client and document that cases that need credentials should really use https://git-scm.com/docs/gitcredentials.

(a) ssh passphrase prompting and (2) one-time, on-terminal http password prompting without requiring persistence do seem like desirable use-cases that are already supported by the underlying tools git/ssh and pip. the case I ran into was where i'm on a foreign machine where it is undesirable to persist creds but I do want to install once from somewhere I have access.

would you still be open to a change which retains user/env-specified GIT_TERMINAL_PROMPT behavior? maybe something like

1. errors and does not block when not attached to a TTY (OR if poetry itself cannot prompt for some reason)
2. does block and prompt for passphrase when attached to a TTY (when underlying git client is prompting)

[github-actions[bot]]

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.