Skip to content
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

Add support for environment variables in package dependencies. #9090

Closed
andreidenissov-cog opened this issue Nov 2, 2020 · 2 comments
Closed
Labels
resolution: no action When the resolution is to not do anything

Comments

@andreidenissov-cog
Copy link

What's the problem this feature will solve?

We are using our private GitHub repositories, which are password (token) protected. These tokens are represented by env. variable(s). We cannot hardcode them in out code base.
So package dependency looks like:
my-project @ git+https://${MY_CREDENTIALS}@github.com/my-team/[email protected]
Now, when this type of dependency is installed from top-level requirements file,
env variable is expanded with no problems. But if package being installed has itself
the same type of dependency, its env variables are left untouched.
This leads to pip failure to install.

Describe the solution you'd like

I would like for env variables to be expanded in all dependencies being processed by pip,
at least in urls being used.

The problem description above is pretty much our real world use case - we have nested private
dependencies in our code structure, and these are protected by tokens which we represent with environment variables.

Alternative Solutions

Well, I guess we could try to play around with git configuration files specifying credentials there,
but that leads to other problems in our setup.

Additional context

@bersbersbers
Copy link

#8828 looks very related.

@uranusjr
Copy link
Member

Not really. Environment variables are already supported in requirements files (which #8828 enhances). This is about package dependencies i.e. things in a package’s metadata. I do not think we should support this since it essentially opens a door for potential attacks to silently obtain system information.

@uranusjr uranusjr closed this as not planned Won't fix, can't repro, duplicate, stale Feb 24, 2024
@uranusjr uranusjr added the resolution: no action When the resolution is to not do anything label Feb 24, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
resolution: no action When the resolution is to not do anything
Projects
None yet
Development

No branches or pull requests

3 participants