Pipenv: AssertionError on pipenv install in ubuntu trusty docker

Created on 5 Jun 2018  Â·  18Comments  Â·  Source: pypa/pipenv

I try to use pipenv in a docker container based on ubuntu trusty. Basically bare metal except for some security patches like apt-get install libssl-dev, libffi-dev and pip install requests[security]

I can run pipenv but whenever I try to call pipenv install I get the following output

root@782753ee5bc0:/# pipenv install requests
Creating a virtualenv for this project…
Using /usr/bin/python (2.7.6) to create virtualenv…
â ‹usage: __main__.py [-h] [-p PYTHON] [-i PACKAGES] [-r REQUIREMENTS] [-d]
                   [-a PROJECT]
                   envname
__main__.py: error: too few arguments

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/python2.7/dist-packages/pipenv/vendor/click/core.py", line 722, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/pipenv/vendor/click/core.py", line 697, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python2.7/dist-packages/pipenv/vendor/click/core.py", line 1066, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python2.7/dist-packages/pipenv/vendor/click/core.py", line 895, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python2.7/dist-packages/pipenv/vendor/click/core.py", line 535, in invoke
    return callback(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/pipenv/cli.py", line 402, in install
    selective_upgrade=selective_upgrade,
  File "/usr/local/lib/python2.7/dist-packages/pipenv/core.py", line 1781, in do_install
    skip_requirements=skip_requirements,
  File "/usr/local/lib/python2.7/dist-packages/pipenv/core.py", line 650, in ensure_project
    ensure_pipfile(validate=validate, skip_requirements=skip_requirements, system=system)
  File "/usr/local/lib/python2.7/dist-packages/pipenv/core.py", line 304, in ensure_pipfile
    project.create_pipfile(python=python)
  File "/usr/local/lib/python2.7/dist-packages/pipenv/project.py", line 571, in create_pipfile
    config_parser = ConfigOptionParser(name=self.name)
  File "/usr/local/lib/python2.7/dist-packages/pipenv/vendor/pip9/baseparser.py", line 149, in __init__
    assert self.name
AssertionError
/usr/local/lib/python2.7/dist-packages/pipenv/_compat.py:86: ResourceWarning: Implicitly cleaning up <TemporaryDirectory '/tmp/pipenv-bI5NJZ-requirements'>
  warnings.warn(warn_message, ResourceWarning)

Running $ python -m pipenv.help yields:

$ python -m pipenv.help output

Pipenv version: '2018.05.18'

Pipenv location: '/usr/local/lib/python2.7/dist-packages/pipenv'

Python location: '/usr/bin/python'

Other Python installations in PATH:

  • 2.7: /usr/bin/python2.7
  • 2.7: /usr/bin/python2.7
  • 3.4: /usr/bin/python3.4m
  • 3.4: /usr/bin/python3.4

  • 2.7.6: /usr/bin/python

  • 2.7.6: /usr/bin/python2
  • 3.4.3: /usr/bin/python3

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '0',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '4.9.60-linuxkit-aufs',
 'platform_system': 'Linux',
 'platform_version': '#1 SMP Mon Nov 6 16:00:12 UTC 2017',
 'python_full_version': '2.7.6',
 'python_version': '2.7',
 'sys_platform': 'linux2'}

System environment variables:

  • LANG
  • TERM
  • LESSCLOSE
  • LANGUAGE
  • SHLVL
  • HOSTNAME
  • PYTHONDONTWRITEBYTECODE
  • LESSOPEN
  • PWD
  • PATH
  • LC_ALL
  • PIP_PYTHON_PATH
  • LS_COLORS
  • HOME
  • _

Pipenv–specific environment variables:

Debug–specific environment variables:

  • PATH: /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
  • LANG: en_US.UTF-8
  • PWD: /

Steps to replicate

Dockerfile

FROM ubuntu:trusty

RUN apt-get update && apt-get dist-upgrade -y && apt-get autoremove -y
&& apt-get install -y --force-yes --no-install-recommends
apt-transport-https
curl
ca-certificates
automake
python-dev
language-pack-en
libffi-dev
libssl-dev
&& apt-get clean

RUN curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py && python get-pip.py
RUN python get-pip.py --force-reinstall
RUN pip install requests[security]

ENV LANG en_US.UTF-8
ENV LANGUAGE en_US.UTF-8
ENV LC_ALL en_US.UTF-8
RUN locale-gen && dpkg-reconfigure locales
RUN pip install pipenv
RUN pipenv install requests

Most helpful comment

after I touched a Pipfile, the problem solved.....

All 18 comments

I guess this is caused by the fact that I'm not in a "project folder" when installing.

root@89918561ad95:/# mkdir foo
root@89918561ad95:/# cd $_
pipenv install requests
Creating a virtualenv for this project…
Using /usr/bin/python (2.7.6) to create virtualenv…
â ‹Already using interpreter /usr/bin/python
New python executable in /root/.local/share/virtualenvs/foo-YJbvrhmB/bin/python
Installing setuptools, pip, wheel...done.
...

But when I run pipenv shell I get Please ensure that the SHELL environment variable is set before activating shell.

Well, did you set the SHELL environment variable?

Running pipenv shell --fancy circumvents the problem

root@89918561ad95:/foo# pipenv shell --fancy
Launching subshell in virtual environment. Type 'exit' or 'Ctrl+D' to return.
# 

@uranusjr No I haven't. But I can't find a section in the docs on this topic.

SHELL is a widely-used environment variable in POSIX systems, used to determine the user’s preferred shell. It is expected to be set to the absolute path of the shell you would like to use, e.g. /bin/bash. Pipenv uses the variable to determine what shell it should launch.

The documentation does assume quite some knowledge on development environment and Python packaging to be consumed. Please do help to clarify if you find it difficult to understand!

root@89918561ad95:/foo# echo "$SHELL"
/bin/bash

Still I can't spawn the shell

root@89918561ad95:/foo# pipenv shell 
Please ensure that the SHELL environment variable is set before activating shell.

I actually have to add export SHELL=/bin/bash to .bashrc to make this work. Is this the intended behaviour?

I don’t have enough information about your environment, but my guess is your scope isn’t set correctly. Docker spawns a new shell for each command, and environment variables don’t live across them.

Also, GitHub is not really for usage questions. You’d probably want to ask on StackOverflow or other discussion venues instead.

No worries I'll figure it out. Thanks for the quick response anyway!

Good luck on that! My invitation regarding documentation contributions still stands though :)

There has been no testing against python 2.7.6 and running sub shells as root isn’t really supported or encouraged. The shell variable has to be set to the same thing as your user account _login_ shell as well, or this will actually never work.

@techalchemy Now that is interesting. Against which python 2 version it has been tested? I'm asking because ubuntu trusty ships with 2.7.6. In my docker images I update to 2.7.15 which I assume should be sane.
As stated in my issue report, I'm attempting to use pipenv in a docker setup. The sub shell should not necessarily be needed but ultimately I want to be able to run some (python) processes in supervisor. I consider keeping my python installations isolated best practice, even in a docker environment. Or do you foresee issues with my approach?

@larsclaussen I think pipenv run is much more useful for your usage than pipenv shell.

And we test against supported releases of python. 2.7.6 is definitely not in that category. I realize that Ubuntu 14.04 is not technically EOL yet, but I mean it’s 4 years old. It’s not super reasonable to build against every point release of every python version just because it appeared in a distro LTS

@techalchemy I get that. And I wouldn't do it either. But from my experience there are quite a few people out there still using such outdated software (instagram for instance was still building on django 1.4 until two years ago)

And if Instagram asked why we aren’t supporting it I’d tell them to hire a team in house if they want support. I actually wouldn’t tell them, because they already do that. If you want to use super outdated unsupported tools you can’t be surprised if new things are not built to support them.

As I said, I'm with you on that point. I'm thankful for the great software you guys are making. Keep it up!

we do support 2.7.15 (or at least that's what we build against) -- pretty sure you'd be fine with 2.13+

after I touched a Pipfile, the problem solved.....

Was this page helpful?
0 / 5 - 0 ratings