On 20 July 2013 17:34, Paul Moore <p.f.mo...@gmail.com> wrote: > On 20 July 2013 00:14, Daniel Holth <dho...@gmail.com> wrote: >> >> it might be nice to update >> the RECORD of installed files as part of the operation. > > > I would argue that keeping RECORD up to date is essential, as not doing so > breaks uninstall. It would also not be in line with PEP 376 It's actually > not entirely clear that PEP 376 allows for a second tool to update an > installation like this anyway (what goes into the INSTALLER file in that > case?)
Perhaps define a solution along the lines of an UPDATES subdirectory with date/time based file names to avoid conflicts? For example: 1. Create a tracking directory as UPDATES/YYYYMMDD_hhmmss 2. Write an INSTALLER file to the tracking directory 3. Copy RECORD to RECORD.prev in the tracking directory 4. Update the main RECORD file with any changes I don't think that's necessary though. INSTALLER is supposed to be about tracking *ownership*, and registering a few extra files in RECORD doesn't change which installer is ultimately responsible for that distribution being present on the system. (Does pip actually do the INSTALLER consistency check to try to avoid getting into arguments with system package management tools?) > Actually, a more general question - to what extent is PEP 376 still relevant > in the light of Metadata 2.0? Something needs to be updated to ensure that > the format and management of the RECORD file remains standardised. There is > a reasonable amount of information that is *only* specified in PEP 376, so > it's not really possible just to deprecate it wholesale... I don't expect any significant changes to the installation database format for metadata 2.0, except to deprecate METADATA in favour of something like "the contents of the distribution's .dist-info directory, including pydist.json as defined in PEP 426 (or later versions of the metadata standard)". In particular, I don't see any reason for RECORD to change as CSV is a good format for that data. If wheel and/or pip adopt a modification tracking system like the one I suggest above, then the updated PEP would standardise that, too (I think such a scheme would be overkill, though). We *might* introduce an optional SQLite based caching mechanism somewhere along the line, but I think that's more appropriately handled on the consumer side of things than it is on the installer side. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
