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

dependencies rules on default environment are not respected on dev #1381

Closed
bruno-fs opened this issue Jan 31, 2018 · 1 comment
Closed

dependencies rules on default environment are not respected on dev #1381

bruno-fs opened this issue Jan 31, 2018 · 1 comment

Comments

@bruno-fs
Copy link

bruno-fs commented Jan 31, 2018

Dependencies pinned on default enviroment are overrided on development env.

I'll use an example to better illustrate a situation:
You are developing a django app and you don't want to use django >= 2, so you install it like this:
pipenv install "django<2"
Then you decide to install django-debug-toolbar and tag it as a development dependency:
pipenv install django-debug-toolbar --dev

The generated Pipfile.lock will have django on default pinned at 1.11.* and on develop it will be locked at 2.*

For now, the way i'm dealing with this copying all non "*" dependencies to develop on Pipfile, so the generated Pipfile.lock will respect it. Not sure if this is indeed a bug or an design decision.

Describe your environment
  1. OS Type: Linux (Ubuntu 16.04.3 LTS)
  2. Python version: 3.6.2
  3. Pipenv version: 9.0.3
Expected result

I expected Pipfile.lock on develop to respect default rules unless they were explicitly overrided on develop.

Actual result

Pipenv.lock overrides the dependencies on default even when they are not specified.

Steps to replicate

Using my example, run pipenv lock with the following Pipfile:

[[source]]

verify_ssl = true
url = "https://pypi.python.org/simple"
name = "pypi"

[packages]

django = "<2"

[dev-packages]

django-debug-toolbar = "*"
@techalchemy
Copy link
Member

Hey @Varnion thanks for the report, this is indeed a bug but we are already tracking this in #1220 and #1255 so I am going to go ahead and close this out for now

in the meantime a workaround is to put django in both sections (ugly I know, sorry for the un-pretty usage)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants