[Distutils] wheel without console_scripts in 0.20.0

Nick Coghlan ncoghlan at gmail.com
Sat Jul 20 10:29:11 CEST 2013

On 20 July 2013 17:34, Paul Moore <p.f.moore at gmail.com> wrote:
> On 20 July 2013 00:14, Daniel Holth <dholth at 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


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Distutils-SIG mailing list