[Python-Dev] PEP 376 : Changing the .egg-info structure
Tarek Ziadé
ziade.tarek at gmail.com
Fri May 15 08:32:29 CEST 2009
2009/5/15 P.J. Eby <pje at telecommunity.com>:
> At 12:21 AM 5/15/2009 +0200, Tarek Ziadé wrote:
>>
>> Hello
>>
>> I'm proposing this PEP, which has been discussed in Distutils-SIG, for
>> inclusion in Python 2.7 and 3.2
>>
>> http://www.python.org/dev/peps/pep-0376/
>>
>> Please comment !
>
> I'd like to reiterate my suggestion that the uninstall record include size
> and checksum information, ala PEP 262's "FILES" section. This would allow
> the uninstall function to validate whether a file has been modified, and
> thus prevent uninstalling a locally-modified file, or a file installed in
> some other way.
good point, I'll re-work that part
>
> It may also be that providing an uninstall API that simply yields files to
> be uninstalled, with data about their existence/modification status, would
> be more useful than a blind uninstall operation with a filter function.
Sure we could have it in that shape, I'll work on this as well.
>
> Also, the PEP doesn't document what happens if a single file was installed
> by more than one package.
It does:
"...as long as they are not mentioned in another RECORD file..."
> Ideally, a file with identical size/checksum that
> belongs to more than one project should be silently left alone, and a file
> installed by more than one project with *different* size/checksum should be
> warned about and left alone.
I think the path is the info that should be looked at. And a warning
could be raised
like you said if a file was manually modified. But I don't think you
want to leave alone
a file with identical size/checksum that belongs to more than one
project when it's not the
same absolute path.
Here's an example why : if two different packages includes the
"feedparser.py" module
(from the FeedParser project) for conveniency, and if you remove one package,
you *do* want to remove its "feeparser.py" module even if it exists in the other
project.
So it's rather changing the PEP text like this:
"...as long as they are not mentioned in another RECORD file, with the
same size/checksum..."
>
> Next, the doc for the metadata API functions seems quite sparse. ISTR that
> I've previously commented on such issues as case- and
> punctuation-insensitivity of project names, and '/' separation in egg_info
> subpaths, but these don't seem to have been incorporated into the current
> version of the PEP.
>
> These are important considerations in general, btw, because project name and
> version canonicalization and escaping are an important part of both
> generating and parsing .egg-info filenemaes. At minimum, the relevant
> setuptools docs that define these standards should be cited.
I'll add more info on that part accordingly then,
>
> Finally, the "Definitions" section also claims that a project installs one
> or more packages, but a project may not contain *any* packages; it may have
> a standalone module, or just a script, data, or metadata.
>
>
ok
Thanks for the feedbacks
--
Tarek Ziadé | http://ziade.org
More information about the Python-Dev
mailing list