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
: /
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
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.....
Most helpful comment
after I touched a Pipfile, the problem solved.....