feat(install): add support for pre-injected packages

[TheKevJames]

• I have added an entry to docs/changelog.md

Summary of changes

Adds support for injecting packages before performing the main package installation. This allows for keyring support via the following, for example for using the Google Artifact Registry:

pipx install \
  --index-url=https://us-python.pkg.dev/my-project/my-index/simple \
  --inject=keyrings.google-artifactregistry-auth \
  my-private-package

This should allow users to install packages with arbitrary additional third-party requirements. This is important especially in cases where those third party requirements are not themselves build dependencies which could be specified via PEP 517: for example, at my company we have a private PyPI index hosted on Google's Artifact Registry which we must install from. The packages themselves should not specify the artifact registry credential helper as a build dependencies, as the packages themselves may be hosted on PyPI itself, this private index, or any other location. Rather, users fetching from that index must be able to specify "...and here's how to do it".

The current best approach I could find through pipx is to make use of --system-site-packages and to install these credential helpers globally. That has a few downsides I would like to avoid, though:

• requires global installations -- what if we want different versions of our credential helpers, or if their dependencies conflict with other global installs?
• requires giving projects access to site packages -- this can have plenty of other side-effects which we may not want!

Open question:

• the --inject flag here has somewhat different semantics than other uses of the "inject" term in pipx. Would renaming to, eg. --pre-inject be clearer?

Test plan

Tested by running the following for several packages hosted on my company's private index. I don't have a great test path to offer folks who don't have access to a private index for testing against. I might be able to look into spinning up a test GCP project and giving a maintainer adhoc access via a Google account? Alternatively, this should support other private indexes such as AWS CodeArtifact, if anyone has access to it for testing!

venv/bin/pipx install \
    --extra-index-url=\https://us-python.pkg.dev/PACKAGE_INDEX/simple\ \
    --inject='keyrings.google-artifactregistry-auth' \
    PACKAGE_NAME

venv/bin/pipx install \
    --pip-args='--extra-index-url=https://us-python.pkg.dev/PACKAGE_INDEX/simple' \
    --inject='keyrings.google-artifactregistry-auth' \
    PACKAGE_NAME

[chrysle]

I think this should be linked with #442

[dukecat0]

@uranusjr Any thoughts on this feature?

[uranusjr]

The feature sounds reasonable, and the implementation looks good to me. I am not sure about the --inject name though, since pipx inject is post-injection and that might confuse people. Would it be more obvious if we name the option e.g. --preinstall-inject? (ideas are very welcomed)

[chrysle]

Would it be more obvious if we name the option e.g. --preinstall-inject? (ideas are very welcomed)

How about shorter --pre-inject?

[uranusjr]

I considered that as well but --pre-inject sounds like doing something before injection, not doing injection before installation. But that’s only my personal feeling.

[chrysle]

Then we could swap preference, e.g. --inject-pre.

[TheKevJames]

Totally open to changing the name! Some other possibilities which could make sense:

• --init / --initial-packages / --initialize-with
• --preinstall / --pre-install-packages
• --inject / --pre-inject / --inject-pre (thanks @chrysle!)

[dukecat0]

I personally think --preinstall would be a better choice, since those packages are installed before the main package.

[uranusjr]

I don’t like --inject and --pre-inject (mentioned previously); no particular preference otherwise.

[chrysle]

@uranusjr Does it sound acceptable to you to use --preinject? I think this removes the focus a bit from your objection.

[TheKevJames]

Updated PR to use --preinstall.

[dukecat0]

Could you add a test for this feature?

[dukecat0]

Thanks for adding this feature! I can add tests for this in a separate PR.