pipenv install progress bar doesn't take dev dependencies into account

[AlJohri]

Als-MacBook-Pro # cat Pipfile
[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[packages]

[dev-packages]

pytest = "*"
coverage = "*"
coveralls = "*"
pep8 = "*"
twine = "*"

Als-MacBook-Pro # pipenv install
No package provided, installing all dependencies.
Installing dependencies from Pipfile.lock…
  🐍   ❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒❒ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell

Notice the 0/0 next to the progress bar.

[kennethreitz42]

$ pipenv install --dev

[AlJohri]

@kennethreitz does pipenv install not install dev dependencies by default? I thought it did

[AlJohri]

I assumed it would work like bundler or npm in this sense: bundle install does everything. or npm install does everything. npm install --only=production does prod only. or like: bundle install --without test development. composer does it this way too might want to rethink this part of the API since there's quite a few examples out there that do the opposite

[kennethreitz42]

you assumed wrong.

[techalchemy]

When I deploy stuff into production and type pipenv install I certainly hope it wouldn't assume it should install development dependencies too... in my view the other tools have some design flaws if their default behavior is to install all development packages into production

[AlJohri]

@techalchemy yeah, I think the reason is that they are opitmizing the command for development since you're generally typing pipenv install by hand when you're developing locally. in production, you'll have a dockerfile or some script that deploys where you put the slightly more verbose:

prod:

bundle install --without development test
RACK_ENV=production bundle exec puma ...
npm install --only=production
NODE_ENV=production npm start

local:

npm install
npm start

bundle install
bundle exec rails server

works either way, just different from what I've used in the past

[uranusjr]

Optimising for development is generally a bad idea because it’s too easy to miss things. You should allow as little by default as possible, and require explicit instruction to allow things on dev. Every development best practice guide will tell you this. Not every project is doing it right, even prominent ones (see MongoDB and MySQL), but I hope Pipenv will continue to do this the right way.

[kennethreitz42]

we're not changing it.

[dopry]

While I don't expect you to change it. I would disagree with the assertion that optimizing for production is correct. It depends on your priorities. If you have a large development team, say 50-100 people and 2-3 release engineers. It's more expensive to train the 50-100 people to run specialized commands, vs the 2-3 release engineers. The specialized behavior for production is often embedded in CI/CD, and the people doing release engineering and CI/CD are I hope more aware of security, reliability and package size concerns than the typical developer who is more focused on delivering working code. So if your priority is to streamline the manual daily work of a large number of developers vs the less frequent, usually automated work of release engineers yout r assertion isn't necessarily accurate. Beyond the work environment and cost-driven concerns looking at open-source, it's also good to simplify the lives if neophytes and new project developers as much as possible to encourage participation and allowing them to contribute with the least cognitive overhead possible.