At 04:14 PM 7/6/2009 +0100, Paul Moore wrote:
2009/7/6 Nick Coghlan <ncogh...@gmail.com>:
> 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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
