Pipx install fails when pip's global index-url is set to a private package repository and user is authenticated via keyring

[thepvguy]

Describe the bug
As stated in the title, pipx install fails when pip's global index-url is:

1. Set to a private package repository
2. The user is authenticated via keyring and not an access token

It seems to be unable to use credentials stored on the system's keyring from inside the created virtual environments because keyring isn't installed (along with an appropriate backend) inside that environment.

Browsing the documentation, I don't see a good way to work around this in the general case.

Environment

• This particular system is a Windows system.
• I'm using Python 3.12.
• In my case, I'm using an Azure artifact feed as a private package index.
• I'm authenticating without using a personal access token.

For reference, here are the steps I've taken to connect to the private repository and install pipx:

1. run pip install keyring artifacts-keyring
2. In %appdata%\pip\pip.ini, I've set the global index-url=https://my_org.pkgs.visualstudio.com/my_project/_packaging/my_feed/pypi/simple/
3. Run pip install pipx

How to reproduce
pipx install some_package

Expected behavior
Installation success

Actual behavior
An error because the package can't be found

Verbose output:

pipx >(setup:1110): pipx version is 1.7.1
pipx >(setup:1111): Default python interpreter is 'C:\Users\tester\AppData\Local\Programs\Python\Python312\python.exe'
pipx >(package_name_from_spec:378): Determined package name: some_package
pipx >(package_name_from_spec:379): Package name determined in 0.0s
pipx >(create_venv:164): Creating virtual environment
creating virtual environment...
pipx >(run_subprocess:175): running C:\Users\tester\AppData\Local\Programs\Python\Python312\python.exe -m venv --without-pip C:\Users\tester\pipx\venvs\some_package
pipx >(run_subprocess:175): running <checking pip's availability>
pipx >(run_subprocess:175): running C:\Users\tester\pipx\venvs\some_package\Scripts\python.exe -c import sysconfig; print(sysconfig.get_path('purelib'))
pipx >(run_subprocess:175): running C:\Users\tester\pipx\shared\Scripts\python.exe -c import sysconfig; print(sysconfig.get_path('purelib'))
pipx >(run_subprocess:175): running C:\Users\tester\pipx\venvs\some_package\Scripts\python.exe --version
pipx >(_parsed_package_to_package_or_url:139): cleaned package spec: some_package
pipx >(install_package:247): Installing some_package
installing some_package...
pipx >(run_subprocess:175): running C:\Users\tester\pipx\venvs\some_package\Scripts\python.exe -m pip --no-input install some_package
pipx >(subprocess_post_check_handle_pip_error:332): 'C:\\Users\\tester\\pipx\\venvs\\some_package\\Scripts\\python.exe -m pip --no-input install some_package' failed
pipx >(subprocess_post_check_handle_pip_error:347): Fatal error from pip prevented installation. Full pip output in file:
    C:\Users\tester\pipx\logs\cmd_2025-02-07_16.48.05_pip_errors.log

Some possibly relevant errors from pip install:
    ERROR: Could not find a version that satisfies the requirement some_package (from versions: none)
    ERROR: No matching distribution found for some_package

pipx >(rmdir:56): removing directory C:\Users\tester\pipx\venvs\some_package
Error installing some_package.

[thepvguy]

My first thought to fix this was to add functionality that

1. Allows pip args in install's --preinstall options
2. Always preinstalls specified packages from a pip-compatible requirements file located somewhere in pipx's home directory.

That would allow me to specify an alternate package index for any packages pip depends on to function on a given system.

This behavior would also take care of any other issues where pip's functionality in a particular environment depends on packages installed from PyPI.