-
Notifications
You must be signed in to change notification settings - Fork 411
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(install): add support for pre-injected packages #900
Conversation
I think this should be linked with #442 |
@uranusjr Any thoughts on this feature? |
The feature sounds reasonable, and the implementation looks good to me. I am not sure about the |
How about shorter |
I considered that as well but |
Then we could swap preference, e.g. |
Totally open to changing the name! Some other possibilities which could make sense:
|
I personally think |
I don’t like |
@uranusjr Does it sound acceptable to you to use |
Adds support for installing 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 \ --preinstall=keyrings.google-artifactregistry-auth \ my-private-package
Updated PR to use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a test for this feature?
Thanks for adding this feature! I can add tests for this in a separate PR. |
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:
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:Open question:
--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!