Add support for keyring as a subprocess subprocess (rather than keyring as an import)

[jfly]

Issue Kind

Brand new capability

Description

Poetry has support for pulling authentication information out of the system keyring. This (largely) works the same as pip's keyring support, and the documentation even references pip's behavior:

Poetry will fallback to Pip style use of keyring so that backends like Microsoft’s artifacts-keyring get a chance to retrieve valid credentials

However, poetry does not have support for invoking keyring as a subprocess (see pip's documentation for this here).

Impact

The author of pip's keyring support actually intended for people to use it as a subprocess, rather than an import ("As the author of the --keyring-provider flag I recommend you use the subprocess provider").

My company would like to use it to avoid a chicken/egg problem (bootstrapping a single systemwide keyring binary with the appropriate keyring backend is easier than doing it for every installation of poetry), and to keep our configuration as in sync with pip as possible.

Workarounds

The alternative is for people to carefully configure their poetry venv to be configured the same as their global keyring installation.

[dimbleby]

poetry is not pip and is not trying to imitate pip, I doubt it will ever add support for pip-specific environment variables

you could try rewording this in terms of a native poetry feature. But given that your workaround already is to configure poetry to do what you want it to do perhaps nothing is missing.

[jfly]

@dimbleby, got it. I've reworded this to just be a feature request asking for support for "keyring as a subprocess" in addition to poetry's "keyring as an import" functionality.

[georgealton]

Thanks bringing this up @jfly - I was just testing poetry support in one of our internal github actions that aims to simplify the authentication process to our package repository, for various package managers / languages.

The subprocess interface to keyring allows for it's use outside of a projects virtual environment without having to configure or inject packages into the poetry virtual environment.

This makes it easier to provide a platform which supports a users choice of python project management tooling - making the decision easier for people to adopt poetry from their current configuration.

Platform teams could then provide development machines, ci machines, with an out of the box configuration which automatically interacts with keyring. Without the need to troubleshoot and direct users to create their projects with a certain set of dependencies installed.

In my case I'd like to configure the pypoetry.toml as such

~/.config/pypoetry/config.toml

[keyring]
enabled = true
provider = 'subprocess'

and it go ahead and it go and execute the current keyring on the Path pulling the credentials from it's stdout.

Thanks!