Should installing pipx shared libs use `pip_args` from the latest package?

Describe the bug

Currently when installing or upgrading the pipx shared libs, the functions _SharedLibs.upgrade() and _SharedLibs.create() accept pip_args arguments. https://github.com/pipxproject/pipx/blob/08bd15610bc406dabe8bf0db4adaba4a3a8b89ea/src/pipx/shared_libs.py#L33 https://github.com/pipxproject/pipx/blob/08bd15610bc406dabe8bf0db4adaba4a3a8b89ea/src/pipx/shared_libs.py#L61

They are used if a normal pipx install needs a shared library create/upgrade, and the pipx install pip args are used to also create the shared libs.

They are NOT used when creating/upgrading the shared libs during a pipx list or any access of an existing venv. (!!)

Recently this failed for me in the following situation: In a Python 3.6 test I was trying to install a package for the first time using the pip arguments --use-feature=2020-resolver. It caused pipx to fail with an error because before installing the package, it went to install the shared libs using pip argument --use-feature=2020-resolver. Since the original Python 3.6 pip doesn’t have that option, it couldn’t even upgrade pip in the first place and crashed.

I’m wondering if we should just remove pip_args from _SharedLibs.upgrade() and _SharedLibs.create(). It seems kind of arbitrary that only when upgrading the shared libs during a package install do they get the pip_args that happen to be used for that package, but not otherwise.

Is there a reason a user would need custom pip args to be used with the installation of the shared libs? If so, maybe we need a different more reliable mechanism.

How to reproduce

Expected behavior

[cs01]

#shipit

[itsayellow]

I’m also kind of assuming that since we inconsistently apply pip_args (sometimes we don’t at all) that if were an issue for people it would’ve come up by now.