Pipfile.lock should use flat collection of dependencies
taion opened this issue · comments
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.
this is contrary to the fundamental design of how pipenv works
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.