$ python -m pipenv.help output
Pipenv version: '11.10.1'
Pipenv location: '/usr/local/lib/python3.6/site-packages/pipenv'
Python location: '/usr/local/bin/python'
Other Python installations in PATH
:
3.6
: /usr/local/bin/python3.6m
3.6
: /usr/local/bin/python3.6
3.6
: /usr/local/bin/python3.6
3.6.5
: /usr/local/bin/python
3.6.5
: /usr/local/bin/python
3.6.5
: /usr/local/bin/python3
3.6.5
: /usr/local/bin/python3
PEP 508 Information:
{'implementation_name': 'cpython',
'implementation_version': '3.6.5',
'os_name': 'posix',
'platform_machine': 'x86_64',
'platform_python_implementation': 'CPython',
'platform_release': '4.16.3-1-ARCH',
'platform_system': 'Linux',
'platform_version': '#1 SMP PREEMPT Thu Apr 19 09:17:56 UTC 2018',
'python_full_version': '3.6.5',
'python_version': '3.6',
'sys_platform': 'linux'}
System environment variables:
HOSTNAME
GPG_KEY
TERM
PYTHON_VERSION
PATH
PWD
LANG
PYTHON_PIP_VERSION
SHLVL
HOME
_
OLDPWD
PYTHONDONTWRITEBYTECODE
PIP_PYTHON_PATH
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH
: /usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
LANG
: C.UTF-8
PWD
: /app
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead.
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.org/simple
ROUND 1
Current constraints:
Finding the best candidates:
Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done
Locking [packages] dependencies…
Using pip: -i https://pypi.python.org/simple
ROUND 1
Current constraints:
Finding the best candidates:
Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done
Updated Pipfile.lock (625834)!
Installing dependencies from Pipfile.lock (625834)…
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead.
Creating a Pipfile for this project…
Warning: --system is intended to be used for Pipfile installation, not installation of specific packages. Aborting.
See also: --deploy flag.
Requires pipenv v11.10.1. Not reproducible in v11.10.0. In an empty directory, run:
$ virtualenv env
$ source env/bin/activate
$ pipenv install
Can you please provide the command you used...
Based on reading your PR you passed —system
which, as the warning states, can’t be used to install individual packages or to do anything besides take a lockfile and put it into a docker container basically.
You’re running inside a virtualenv I can see, so passing —system
is almost certainly not what you want to do unless your goal is actually to install packages in your systems site packages directory. These warnings are there in this version for a reason
Let me know if that clears things up, I see you already opted to move away from pipenv but I’m fairly confident that all you actually needed to do in this case was not pass —system
. This argument really is basically never what you want unless you’re an isolated container for deployment.
The command used is only pipenv install
, see also Steps to replicate in the original post. This occurs when running inside an existing virtualenv with no existing Pipfile/Pipfile.lock.
Please note that "Warning: --system is intended to be used for Pipfile installation, ..." is printed despite not using the --system
argument.
@kvikshaug er right, yes, totally missed that... people don't normally fill out the issue template accurately :sweat_smile:
I thought I fixed this before releasing... but yeah this is definitely still present... sorry, this is bad
No problem :slightly_smiling_face: to be clear, the linked PR is a bit misleading and we are not moving away from pipenv as a tool in general. Thanks for following up.
Please release this.
I'm still seeing this issue on version 11.10.4, I checked my pipenv/core.py file, it includes the change of #2091.
(venv) # pipenv install -r requirements.txt
Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project. You can set PIPENV_IGNORE_VIRTUALENVS=1 to force pipenv to ignore that environment and create its own instead.
Requirements file provided! Importing into Pipfile…
Warning: --system is intended to be used for Pipfile installation, not installation of specific packages. Aborting.
See also: --deploy flag.
(venv) # pipenv --version
pipenv, version 11.10.4
I am also still seeing this error with pipenv v11.10.4.
In the fix, should it have been the following?
if (system or allow_global) and not PIPENV_VIRTUALENV:
@pegler thanks for the fix and sorry for the logic error!
FYI: this is blowing up on me, and I worked around it as described by @pegler , so hopefully this re-fixed fix can be released soon.
This still seems to be an issue in 2018.05.18... has the fix been released and I'm missing something?
There's a fix on master but there hasn't been another relase yet
For everybody having problems with pipenv: try poetry
https://github.com/sdispater/poetry
I was waiting for a whole month for this fix, but after pipenv disappointed me several times now, i switched .. pipenv still has not earned its 1.0 release number!
Your comment is nonsensical since pipenv uses calver. Separately, version number does not imply how mature a project is. Maybe poetry is a good alternative to pipenv, but using version as a selling point is not a good argument.
Your comment is nonsensical since pipenv uses calver.
come on - have a look at the version history. Switching to calver just recently only tells me that also the pipenv devs think it has been hilarious to be at version 11 and still not being able to export a rock solid version of a requirements.txt without multiple versions of the same modules resulting in unusable exports.
Or just look at this lil but serious issue!
Since i first tried to start using pipenv in December i fell in love with the superior concept. But being put down so many times i still have a requirements.txt in my projects as a fallback, because i needed it so many times now. It just isnt fun to still need it after 7 months and 11 major versions!
Separately, version number does not imply how mature a project is.
Ok, thats your take on version numbers .. im not going to start a discussion on this one.
I think this is just a difference of opinion on the expectations of an open source project. I saw this bug wasn't fixed so I submitted a pull request with the fix. The volunteers managing this project haven't yet released a new version to pypi.
If you think this project could be improved then I think you should contribute.
yep, release is coming out tomorrow, many changes and improvements.
@kakulukia If you aren't able to contribute in a mature and productive way, please refrain from contributing at all. Packaging is a complicated subject and the tooling is quite difficult; the next release of pipenv brings many internal changes and improvements, including an upgrade to pip 10 and an upgrade to piptools. As we are all volunteers, this took considerable time and effort on the side.
It works if you first install pipenv
before_script:
pip install pipenv
pipenv install
Most helpful comment
Please release this.