Pip version in the Pipfile.lock about pipfile

[kennethreitz]

Adding the pip version as metadata is likely a wise decision, but might not be neccessary. I'll have to think about it.

The idea is that the lockfile api will be locked, but the pipfile functionality could possibly be ammended later, potentially, utilizing the mechanisms provided in the pipfile (e.g. custom groups).

[pradyunsg]

@kennethreitz Have you thought about this?

[kennethreitz]

don't think it's needed at this point

[dstufft]

I think that we should either do this or #5. Personally I find the idea in #5 to be better largely because one of the goals of splitting this out into a separate library + spec is so that other tooling can reasonably interact with this file besides pip itself. I'm going to close this issue, but mention on #5 that it could possibly also be solved by embedding the pip version instead.

[AvnerCohen]

Sure. no problem. My last comment on this would be to suggest reading through the pains of adding version into the pipfile.lock /gemfile.lock later in the process:
http://bundler.io/blog/2015/06/24/version-1-10-released.html#bundled-with

pipfile has this unique advantage of being built long after some other platforms, some even has 2nd generation lock file (yarn.lock includes learnings from npm.lock).

I really think it would be beneficial to to try and read through some of these existing tools, yarn, which is the latest and greatest of these, is designed with some very interesting features around security and performance.