Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
2009/7/6 Nick Coghlan
: P.J. Eby wrote:
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
But if it's based on PEP 302 protocols and if the pkgutil code works with the sys.meta_path hook, setuptools could then provide its loader, based on its EggFormats and act as a provider without being broken.
You misunderstand me. The whole point of putting .egg-info in distutils in the first place was to enable setuptools to detect the presence of disutils-installed packages. That's what's broken by changing the name.
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. 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.
My site-packages has a confusing mix of egginfo directories and files. Note that I NEVER use setuptools other than where an existing package's setup.py requires it. In that case, I still only do python setup.py bdist_wininst and install the generated installer.
So is PEP 376 going to be able to cope with the stuff I have installed at the moment? If not, what's the point???
If I understand Tarek's proposal correctly, then no, it will not cope.
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. 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.
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.
On Mon, Jul 6, 2009 at 6:58 PM, P.J. Eby
My site-packages has a confusing mix of egginfo directories and files. Note that I NEVER use setuptools other than where an existing package's setup.py requires it. In that case, I still only do python setup.py bdist_wininst and install the generated installer.
If you end up with confusing mix of egginfo directories and files, that's because for the packages that uses setuptools in their setup.py, it patches distutils and to creates its own egg-info format.
So is PEP 376 going to be able to cope with the stuff I have installed at the moment? If not, what's the point???
If I understand Tarek's proposal correctly, then no, it will not cope.
Why that ? Can you detail ? On a system that uses only plain distutils distributions, it'll work.
2009/7/6 P.J. Eby
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.
participants (3)
-
P.J. Eby
-
Paul Moore
-
Tarek Ziadé