You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In enterprise environments, TLS interception is commonly used necessitating the use of truststore for downloading packages over HTTPS. That pip package is installed in the same environment as pip runs in and then activated using the line use-feature = truststore in pip.conf/.ini. Without doing so, the user will face TLS/SSL verification errors as certifi most of the time doesn't contain the right TLS certificates to support TLS interceptors.
When running pipx install (whether using --system-site-packages) or not, this does create a chicken-and-egg problem: the pip inside of the new pipx environment doesn't have the truststore package and so can't install anything - including the truststore package. This chicken-and-egg problem also causes the --preinstall option to be useless here.
When building the shared libraries, provide that pip with access to (or use it to install a wheel in the fresh virtual environment of a) recent version of the truststore package. This behavior could be opted into with a command line switch.
Describe alternatives you've considered
I can work around this issue by manually invoking the pip in the shared libraries to install truststore. You can find more details in the discussion thread I had here.
The text was updated successfully, but these errors were encountered:
How would this feature be useful?
In enterprise environments, TLS interception is commonly used necessitating the use of truststore for downloading packages over HTTPS. That
pip
package is installed in the same environment aspip
runs in and then activated using the lineuse-feature = truststore
inpip.conf/.ini
. Without doing so, the user will face TLS/SSL verification errors ascertifi
most of the time doesn't contain the right TLS certificates to support TLS interceptors.When running
pipx install
(whether using--system-site-packages
) or not, this does create a chicken-and-egg problem: thepip
inside of the newpipx
environment doesn't have thetruststore
package and so can't install anything - including thetruststore
package. This chicken-and-egg problem also causes the--preinstall
option to be useless here.Please see this discussion thread for background.
Describe the solution you'd like
When building the shared libraries, provide that
pip
with access to (or use it to install a wheel in the fresh virtual environment of a) recent version of thetruststore
package. This behavior could be opted into with a command line switch.Describe alternatives you've considered
I can work around this issue by manually invoking the
pip
in the shared libraries to installtruststore
. You can find more details in the discussion thread I had here.The text was updated successfully, but these errors were encountered: