On Feb 26, 2014, at 6:17 PM, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:

> It makes perfect sense to version the dist-info directory.
> You don’t know how to interpret the files inside that directory without it.
> You have to rely on heuristics and guessing.

Not if you specify up front how it will work, which is doable.

It's not clear to me if you mean putting the metadata version in the directory name itself - if so, that's a -1 from me. It doesn't actually make things better as far as the PEP 376 database logic goes, given that a site-packages could have any number of dist-info dirs which could have been installed with different metadata versions.

No I don’t mean the directory name.


If you mean putting some marker inside the directory, then pydist.json is as good a place as any, because as packaging evolves, the chances are that pydist.json will need to contain metadata version information telling how to process it, and there's little point in providing the information in two places. All of the legacy stuff is in separate files purely for speed of processing or through historical accident, but those are implementation details which should be under the hood as far as possible.

There is always going to be multiple files, it’s kind of silly to tie the definition of the dist-info directory to the pydist.json when that’s perhaps not the file you care about how to interpret. How do you interpret the RECORD file? The INSTALLER file? 

The versioned definition of the dist-info directory would say, “RECORD file is an XYZ file” “pydist.json is an ABC file”. It’s the only sane way to handle the case where you can have an unbounded number of unknown files in the directory.


Regards,

Vinay Sajip




-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA