pipenv: Confusing error message when run in Dockerfile

Can we reopen this?

I disagree that Docker is “a pathological environment”! In particular, if Pipenv doesn’t work out of the box with an official Python Docker image, something is wrong (though I’m not sure whether it’s the image or Pipenv that should be fixed.)

FWIW, here’s my repro:

FROM python:3.6.4

RUN pip install pipenv
RUN pipenv --three

Output:

Sending build context to Docker daemon  14.19MB
Step 1/3 : FROM python:3.6.4
 ---> 336d482502ab
Step 2/3 : RUN pip install pipenv
 ---> Using cache
 ---> 91428d6b95e1
Step 3/3 : RUN pipenv --three
 ---> Running in 492b2b8a1779
Creating a virtualenv for this project…
Using /usr/local/bin/python3 (3.6.4) to create virtualenv…
usage: __main__.py [-h] [-p PYTHON] [-i PACKAGES] [-r REQUIREMENTS] [-d]
                   [-a PROJECT]
                   envname
__main__.py: error: the following arguments are required: envname

Virtualenv location:
Creating a Pipfile for this project…
Traceback (most recent call last):
  File "/usr/local/bin/pipenv", line 11, in <module>
    sys.exit(cli())
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 1043, in invoke
    return Command.invoke(self, ctx)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/pipenv/cli.py", line 152, in cli
    core.ensure_project(three=three, python=python, warn=True, site_packages=site_packages)
  File "/usr/local/lib/python3.6/site-packages/pipenv/core.py", line 672, in ensure_project
    ensure_pipfile(validate=validate, skip_requirements=skip_requirements)
  File "/usr/local/lib/python3.6/site-packages/pipenv/core.py", line 321, in ensure_pipfile
    project.create_pipfile(python=python)
  File "/usr/local/lib/python3.6/site-packages/pipenv/project.py", line 416, in create_pipfile
    config_parser = ConfigOptionParser(name=self.name)
  File "/usr/local/lib/python3.6/site-packages/pipenv/vendor/pip9/baseparser.py", line 149, in __init__
    assert self.name
AssertionError
The command '/bin/sh -c pipenv --three' returned a non-zero code: 1

In case it helps others I was able to solve this issue by setting WORKDIR to /opt/app:

FROM python:3.6.4-stretch

WORKDIR /opt/app

# build your stuff....

1. pipenv --three definitely is supposed to work (I use it too)
2. Docker problems generally boil down to either (1) / has no name and thus cannot be hashed for generating virtualenv or (2) python version and path problems. So for now, the solution is to make the WORKDIR not be / (which is the default). For context - pipenv hashes the / to figure out virtualenv name, and I think when it doesn’t exist it hits a pathological codepath…

I had a similar issue and it was just that PYTHONPATH and PYTHON_VERSION environment variables weren’t set in the docker container.

An example of my dockerfile can be found at: https://gist.github.com/aljp/811030019a711532eda77cf07408458a

I’m currently using this docker image in a circleci build and it works there, however, when I attempt to run the circleci builds or docker run locally I get the same error.

If you build that image and run docker run -it --rm my/repo:circleci-latest /bin/bash and then run pipenv install --dev you’ll see the error:

Creating a virtualenv for this project…
⠋usage: pew [-h] [-p PYTHON] [-i PACKAGES] [-r REQUIREMENTS] [-d] [-a PROJECT]
           envname
pew: error: the following arguments are required: envname

Virtualenv location: 
Creating a Pipfile for this project…
Creating a virtualenv for this project…
⠙usage: pew [-h] [-p PYTHON] [-i PACKAGES] [-r REQUIREMENTS] [-d] [-a PROJECT]
           envname
pew: error: the following arguments are required: envname

Virtualenv location: 
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
An unexpected error occurred while accessing your virtualenv's python installation!
Please run $ pipenv --rm to re-create your environment.

Turns out the docker container was just missing the PYTHONPATH and PYTHON_VERSION environment variables, so running the container with docker run -it --rm -e PYTHONPATH=/usr/local/bin -e PYTHON_VERSION="3.6.1" my/repo:circleci-latest /bin/bash seems to work.

Perhaps reopen this? Here’s a minimal reproducer:

$ cat Dockerfile 
FROM python:3.6.3
RUN pip install pipenv
RUN pipenv install

$ docker build .
Sending build context to Docker daemon  4.608kB
Step 1/3 : FROM python:3.6.3
 ---> a8f7167de312
Step 2/3 : RUN pip install pipenv
 ---> Using cache
 ---> 14db7304c3a0
Step 3/3 : RUN pipenv install
 ---> Running in b9253f7914a2
Creating a virtualenv for this project…
usage: pew [-h] [-p PYTHON] [-i PACKAGES] [-r REQUIREMENTS] [-d] [-a PROJECT]
           envname
pew: error: the following arguments are required: envname

Virtualenv location: 
Creating a Pipfile for this project…
Creating a virtualenv for this project…
usage: pew [-h] [-p PYTHON] [-i PACKAGES] [-r REQUIREMENTS] [-d] [-a PROJECT]
           envname
pew: error: the following arguments are required: envname

Virtualenv location: 
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
An unexpected error occurred while accessing your virtualenv's python installation!
Please run $ pipenv --rm to re-create your environment.
The command '/bin/sh -c pipenv install' returned a non-zero code: 1

I can’t control how it is run, ie I need to make the Dockerfile work on its own, but so far I haven’t fixed the problem with ENV statements.