2009/5/15 P.J. Eby <p...@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 _______________________________________________ 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
