Pipenv: Allow Pipfile to consume environment variables

Created on 12 Mar 2018  Â·  25Comments  Â·  Source: pypa/pipenv

It would be awesome if Pipfile could be parsed to allow for environment variables.

While it's great that pipenv supports private indexes, it's annoying if those indexes require credentials—it's bad practice to store them in source control:

[[source]]

url = "https://{{ MY_USERNAME }}:{{ MY_PASSWORD }}@my_custom_repo.jfrog.io/simple"
verify_ssl = true
name = "pypi"

Happy to contribute a PR for this if this gets some thumbs.

Future Discussion Type

Most helpful comment

It would be nice if we can have environment variables loaded throughout the entire Pipfile. E.g.

[dev-packages]
my-package = {path="${PATH_TO_REPO}", editable = true}

All 25 comments

:+1:

@kennethreitz what do you think about making this section able to inherits values from a global setting file, such as /etc/pipenv.conf (a-la /etc/pip.conf), so all Pipfile within a private organisation can use the same internal repository (nexus, artifactory, other,...)

no

@gsemet I believe pipfiles will use sources specified in your pip.conf now though

When we create a pipfile for you, it will be populated with sources from pip.conf.

not sure, we use our internal nexus cache in pip.conf:

$ cat /etc/pip.conf
[global]
trusted-host = nexus.mycompagny.fr
index = http://nexus.mycompagny.fr/repository/pypi/pypi
index-url = http://nexus.mycompagny.fr/repository/pypi/simple

when executing pip install on its own, it uses this server.

when creating a pipfile:

$ pipenv install request
...
$ cat Pipfile                                                                                                                                                                                              
[[source]]
name = "pypi"
verify_ssl = true
url = "https://pypi.python.org/simple"
...

we pick up user pip conf i think, not global pip conf.

That sounds potentially dangerous if you’re storing credentials in pip.conf.

@kennethreitz, I was reading another issue where you referred to the Pipfile as the source of truth. I think this is a great idea and should stay that way.

On Mar 14, 2018, at 9:14 AM, Kenneth Reitz notifications@github.com wrote:

here's the code: https://github.com/pypa/pipenv/blob/master/pipenv/project.py#L419

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

we could detect high-entropy strings automatically (or just urlparse).

@dvf pipfile is def the source of truth.

i think environment variable injection is a good idea though

url = "https://$PYPI_USERNAME:[email protected]/simple"

or just https://[email protected]/simple

We raise an error if PYPI_CREDS isn't in os.environ.

If we only check PYPI_CREDS, we're assuming that a user would only have a single source defined in their Pipfile. I think we should allow for any environment variable—similar to how Docker allows you to use Environment Variables in Compose files.

  • Pipfile is the ultimate source of truth
  • Any value can contain an environment variable, but nothing else

Of course we'd support any.

i'm just using that as an example

Oh gotcha đź‘Ť

Do you have any ideas about how you see this being implemented?

@kennethreitz - env variable expansion is something I'd be happy to implement unless somebody else wants to (prob have time next weekend), but also happy to leave to other ambitious and/or helpful folks

@jtratner I was going to take a stab at it. Feel free to leave some suggestions in advance though.

oh go for it @dvf :)

Resolved by #1769 and #1809

It would be nice if we can have environment variables loaded throughout the entire Pipfile. E.g.

[dev-packages]
my-package = {path="${PATH_TO_REPO}", editable = true}

@njgrisafi The reason this does not work appears to be due to https://github.com/pypa/pipenv/blob/8aa9283fda2e8cc532f517969f5f3e1969e8d4a2/pipenv/project.py#L519 using tomlkit instead of pipfile.api.PipfileParser

However, this gets further complicated by the fact that the path is copied into the Pipfile.lock. The way inject currently works, it that it injects the values at parse time, which means by the time you get to writing the lock file, it will write the value of the the environment variable, not the ${FOO} syntax. :(

I agree, this feature working on path would be very much desired for me too. I want to run a Pipfile in and out of a docker container, but currently implementation limits this.

Was this page helpful?
0 / 5 - 0 ratings