Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v11.10.1: initial pipenv install in existing virtualenv fails #2078

Closed
kvikshaug opened this issue Apr 27, 2018 · 19 comments
Closed

v11.10.1: initial pipenv install in existing virtualenv fails #2078

kvikshaug opened this issue Apr 27, 2018 · 19 comments
Labels
Type: Bug 🐛 This issue is a bug. Type: Regression This issue is a regression of a previous behavior.
Milestone

Comments

@kvikshaug
Copy link

kvikshaug commented Apr 27, 2018

$ 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


Expected result
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)…
Actual result
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.
Steps to replicate

Requires pipenv v11.10.1. Not reproducible in v11.10.0. In an empty directory, run:

$ virtualenv env
$ source env/bin/activate
$ pipenv install
@techalchemy
Copy link
Member

Can you please provide the command you used...

@techalchemy
Copy link
Member

techalchemy commented Apr 27, 2018

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

@techalchemy
Copy link
Member

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.

@kvikshaug
Copy link
Author

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.

@techalchemy
Copy link
Member

@kvikshaug er right, yes, totally missed that... people don't normally fill out the issue template accurately 😅

I thought I fixed this before releasing... but yeah this is definitely still present... sorry, this is bad

@techalchemy techalchemy reopened this Apr 28, 2018
@techalchemy techalchemy self-assigned this Apr 28, 2018
@techalchemy techalchemy added Type: Bug 🐛 This issue is a bug. Type: Regression This issue is a regression of a previous behavior. labels Apr 28, 2018
@kvikshaug
Copy link
Author

No problem 🙂 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.

@kakulukia
Copy link

Please release this.

ioparaskev added a commit to cenotes/cenotes that referenced this issue May 8, 2018
- Removes py34 environment for tox envs that use the
requirements-dev.txt. It seems that in python 3.4 a sphinx requirement
does not have all their dependencied pinned and so the pinning check
during installation fails. py34 is kept in the integration tox env that
uses pipenv install
- Keeps pipenv to 11.10.0 in tox ini due to existing issue with travis
and tox (pypa/pipenv#2078)
ioparaskev added a commit to cenotes/cenotes that referenced this issue May 8, 2018
- Removes py34 environment for tox envs that use the
requirements-dev.txt. It seems that in python 3.4 a sphinx requirement
does not have all their dependencied pinned and so the pinning check
during installation fails. py34 is kept in the integration tox env that
uses pipenv install
- Keeps pipenv to 11.10.0 in tox ini due to existing issue with travis
and tox (pypa/pipenv#2078)
@leira
Copy link

leira commented May 11, 2018

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

@pegler
Copy link
Contributor

pegler commented May 11, 2018

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:

@techalchemy
Copy link
Member

@pegler thanks for the fix and sorry for the logic error!

@megahall
Copy link

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.

FlowFX added a commit to FlowFX/flowfx.de that referenced this issue May 27, 2018
ioparaskev added a commit to cenotes/cenotes-lib that referenced this issue May 29, 2018
- Keeps pipenv to 11.10.0 in tox ini due to existing issue with travis
and tox (pypa/pipenv#2078)
ioparaskev added a commit to cenotes/cenotes-lib that referenced this issue May 29, 2018
- Keeps pipenv to 11.10.0 in tox ini due to existing issue with travis
and tox (pypa/pipenv#2078)
@jakemwood
Copy link

This still seems to be an issue in 2018.05.18... has the fix been released and I'm missing something?

@pegler
Copy link
Contributor

pegler commented Jun 15, 2018

There's a fix on master but there hasn't been another relase yet

@kakulukia
Copy link

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!

@pegler
Copy link
Contributor

pegler commented Jun 15, 2018

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.

@kakulukia
Copy link

kakulukia commented Jun 15, 2018

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.

@pegler
Copy link
Contributor

pegler commented Jun 15, 2018

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.

@techalchemy
Copy link
Member

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.

@ezrogha
Copy link

ezrogha commented Mar 26, 2019

It works if you first install pipenv

before_script:
pip install pipenv
pipenv install

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug 🐛 This issue is a bug. Type: Regression This issue is a regression of a previous behavior.
Projects
None yet
Development

No branches or pull requests

8 participants