Include a 'version' tag in Pipfile.lock

[defnull]

No description provided.

[dstufft]

Yes I thought about this as well. Ideally this is something that is dependent of the serialization mechanism entirely so that we can change serialization formats as needed. Something like:

version=1
{
    "_meta": {
        "sources": [
            {"url": "https://pypi.org/", "verify_ssl": true},
        ]
     },
    "default": [
        {"name": "requests", "version": "0.11.2", "hash": "..."},
        {"name": "Django", "version": "1.6", "hash": "..."},
        {"name": "pinax", "git": "git://...", "ref": "1.4", "editable": true},
    ],
    "development": [
        {"name": "nose", "version": "1.3.7", "hash": "..."},
    ]
}

It makes parsing slightly harder in that you have to read the first line to get the version, and then only parse line 2+ for the rest of the data, but it means we can easily switch to any other serialization format we want.

[defnull]

I don't agree. There are only a handful of serialization formats that may be interesting and auto-detecting the format is not that hard. Breaking the format this way would render most existing tools useless. You are basically introducing a non-standard container format here.

[Screwtapello]

Even with a version tag, it likely won't be practical to change the serialisation mechanism; there's going to (eventually) be a lot of code in the wild that just assumes that the version number will always be 1. Much like every future version of HTML is constrained to be intelligible to an HTML4 parser, every future version of the lockfile spec is going to have to work with a version 1 parser.

[dstufft]

Eh, I disagree. People will bake all sorts of random assumptions into their code. If we state that new versions are a thing they need to support then that's sort of it. Otherwise we can never add any new syntax to the lock file at all because someone might not correctly be handling unexpected new data.

[Screwtapello]

A half-assed, "it worked once, never touch it again" Pipfile.lock parser will never support multiple versions, no matter how many warnings you put in the file-format spec, because people writing such parsers won't even look at the spec. On the other hand, a half-assed parser is almost guaranteed to ignore parts of the file it doesn't understand, because anything else is wasted effort.

No file-format decision can guarantee that every implementation follows the specification. However, a file-format that expects and requires laziness will likely be more interoperably and reliably implemented than one which requires even minimal attention to other details.

[dstufft]

In #28 it was suggested to embed the pip version inside of the Pipfile.lock. I believe that this has the same fundamental idea as this issue, provide a mechanism by which you can version the Pipfile.lock. Ultimately, I think just a spec version is a better idea than a "pip version", because part of the goal here is to allow other tooling to interact with these files independetly of pip (for example, IDEs) without needing to pretend they are pip.

[kennethreitz]

I'll add this to pipenv.

[kennethreitz]

Declaring current version as 1.

[kennethreitz]

{"_meta": {"pipfile-spec": 1}}

[kennethreitz]

added to the spec: https://github.com/pypa/pipfile/blob/master/README.rst#pipfilelock