2009/7/1 R. David Murray rdmurray@bitdance.com:
I haven't read the PEP in detail since it's outside my area of interest and knowledge(*), but my understanding of the goal is that the PEP is providing an _infrastructure_ for system-level package management tools. The uninstall function is part of that infrastructure, but since distutils isn't a package manager itself (it's an install program), distutils as currently organized can't really handle uninstall except as outlined in a section you may have clipped from the above context (ie: when setup.py from the original package is available).
From a Windows user's POV, "install program" = "package manager". And
an install program needs an uninstall feature. I know Linux users with their advanced dependency-managing package managers feel that this is a stone-age view, and they may be right, but the PEP needs to take the Windows situation into account.
The question is what do the people who do real package management (linux distribution level package management and the equivalent) think? I'm guessing they are happy with just having the function for their package management tools to call when needed, since (I'm hoping) they are part of the distutils sig....
Don't forget that the maintainers of the bdist_wininst, bdist_msi and bdist_rpm code *are* the distutils maintainers - so to that extent, the PEP has to say how *those* aspects of package managers are covered. Unless another PEP is accepted saying that support for bdist_xxx is being dropped [1], this part of distutils cannot be ignored.
So, if my understanding of the overall goal is correct, it looks to me like the PEP is missing a "motivation" section that talks about system package managers.
Possibly. If so, though, it must discuss the above 3 cases which are part of core distutils.
Paul.
[1] A PEP I plan on strongly opposing!