Pipfile.lock should use flat collection of dependencies

[taion]

Currently, Pipfile.lock puts groups at top-level, then lists out locked dependencies for each group separately.

This is not, for example, how npm or Yarn handle this. Both of those package managers have a flat list of locked packages, with dev as a flag for each package.

The latter setup is superior, as it would make it structurally impossible to have version conflicts in the lockfile per https://github.com/kennethreitz/pipenv/issues/1137.

As such, Pipfile.lock should use a flat collection of dependencies, as by construction it should not be possible for locked default and development to conflict, as that would give rise to inconsistencies and unsatisfied transitive dependencies.

[kennethreitz]

this is contrary to the fundamental design of how pipenv works

[taion]

I'm not sure Pipenv should be dispositive here – Pipfile is meant to be a spec for locking down versions, and the lockfile should correspond.

I did a quick check across other locking package managers. All of the following use a flat package structure in their lockfiles:

• npm
• Yarn
• Bundler
• Cargo

If there's a design decision that makes it impossible to ensure that production and development dependencies do not conflict, then the correct thing to do is to revisit that design decision.