At 01:58 PM 7/8/2009 -0400, Eric Smith wrote:
I really don't see this use case. Supporting multiple installers for
the same file (or even just trying to prevent two installers from
writing the same file)? Wouldn't you be better off just saying an
installer can't overwrite any existing file?
Likewise, I don't see a use case for installing with one installer
and uninstalling with another.
Put those two together, and the mechanism that an installer uses to
record what files it installed is a private implementation detail.
You'll have to ask Tarek about that. As I've said in another email,
if I were doing this for setuptools I'd just go and do it; it's
already on my backlog of things to do. The point of the PEP is to
provide an uninstall facility for the distutils, and to expose those
records via an API so that other tools can be built on top of it.
Whether anything other than distutils-based tools will actually use
the format directly is entirely irrelevant to the PEP's merits, since
bdist_* tools and platform-specific distutils installers may need to
read or write the format. Hence, a PEP is appropriate to describe a
format and API for the distutils family of tools to operate on.
The specific proposed format is based on an existing de facto
standard for installed package metadata, so that the many existing
packaging tools based on that other format and existing APIs can
easily read or write this data, and so that the API can also be used
as a way to detect the presence of already-installed distributions of
software -- even ones installed other ways.
_______________________________________________
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
