[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