Plaintext backend does not allow installing

[Time0o]

Describe the bug

I have the following situation: In a GitLab CI job, running inside a debian:latest Docker container, I want to install a package from a GitLab package registry using the simplest possible keyring setup. This is to assert that the installation instructions I provide to users in the README actually do what they are supposed to do, I don't care if the backend used is actually secure.

Here is my job definition:

publish_package_test:
  script:
    - apt-get update
    - apt-get install -y --no-install-recommends python3 python3-venv
    - python3 -m venv python_venv --upgrade-deps
    - source python_venv/bin/activate
    - pip install keyring keyrings.alt
    - echo ${CI_JOB_TOKEN} | keyring set gitlab.com gitlab-ci-token
    - pip config set --user global.keyring-provider import
    - pip config set --user global.extra-index-url https://gitlab.com/api/v4/groups/${CI_PROJECT_NAMESPACE_ID}/-/packages/pypi/
    - pip install --no-cache-dir ${CI_PROJECT_NAME}

This fails silently because pip install will still prompt for username/password. This does not happen on my local Ubuntu machine which uses the proper SecretService backend. keyring's README contains instructions for using this backend in a privileged Ubuntu container. But my container runs Debian and is not privileged so I hoped I could just use a "dummy" backend. Why can't I?

To Reproduce

• docker run -it debian:latest
• Install keyring and keyring.alt in a virtual env.
• Store a username and password for some package registry in keyring and configure pip to use the import provider.
• Attempt to install a package via pip install.

Expected behavior

pip install will use the credentials provided to keyring, even when using the plaintext backend.

Environment

debian:latest container.

$ pip list | grep keyring
keyring            25.2.0
keyrings.alt       5.0.1

$ keyring --list-backends
keyring.backends.fail.Keyring (priority: 0)
keyrings.alt.file.PlaintextKeyring (priority: 0.5)