[Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata

[Paul Moore]

2009/7/6 P.J. Eby <pje at telecommunity.com>:
> At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
>> This is getting confusing. Is Phillip saying that setuptools will cope
>> with the file changing to a directory without modification, but it
>> can't handle a change in the name?
>
> The existing versions of setuptools will read a file or a directory with no
> problem; it's the name change that will require a code change, and it's a
> rather more complex issue than just one name change, because it'll need to
> support both names.

If PEP 376 is the standard, setuptools can just use that. Whether you
have to handle backward compatibility issues so that newer versions of
setuptools work with older metadata layouts is largely an internal
setuptools issue. While I don't want to gratuitously break setuptools,
it already supports something like 3 formats, as I understand it, so
adding a 4th shouldn't be the end of the world.

> What's more, on the build/install side, it'll have to figure out whether to
> use the new name or the old name when creating a project's metadata for
> installation in single-version mode.  In other words, this will likely
> affect pip as well, or at least the parts of setuptools that pip uses.

And yet, there have been no adverse comments from users of pip, or
buildout, or any of the other tools that this PEP is targeted at. So
either there's a huge chunk of the affected community that's unaware
of this discussion (which I doubt), or they have no problem with this,
or their interaction is via setuptools, and so as long as setuptools
is changed, they are fine. (The other benefit of the PEP is that if
setuptools *doesn't* change, they have alternative tools to build
their own interface, although they may not want to be forced to do
this...)

>> If setuptools is not going to change to conform to PEP 376, then any
>> tools built using PEP 376 will fail to recognise my coverage install.
>
> I'm all in favor of adding RECORD support to setuptools; it was in fact my
> idea to have the file there in the first place.
>
> Adding a RECORD file doesn't introduce any new and weird name migration
> requirements, which is why I'd rather not change the extension if we can
> avoid it.

You don't give any reasons why you pick and choose what changes you're
happy with - "weird name migration requirements"  isn't very specific.

> Reading both names is painful, writing both is more so, and I'm not sure how
> many tools/users *besides* setuptools will be affected by a name change.

Don't forget - I made that point when I said I wasn't too bothered
about what was an internal name change.

>> > How much information does setuptools actually need in order to tell that
>> > a distribution is already present? Presumably the existing .egginfo
>> > files generated by distutils are sufficient for that task?
>>
>> It appears so, but setuptools doesn't use (or create!!!) those files
>> in its own installer formats.
>
> Setuptools treats an .egg-info file as if it were a PKG-INFO file contained
> in an .egg-info directory.  This allows it to treat distutils-supplied
> .egg-info files as if they were setuptools-supplied .egg-info directories
> containing exactly one file.

Hey, look - you get to *remove* some compatibility code!

Paul.