Re-posting for visibility: http://groups.google.com/group/the-fellowship-of-the-packaging/browse_thread... While working on the new pysetup commands I ran into some issues when trying to uninstall projects based on distribute/setuptools. The current install method used in packaging is to "shell" out and call: # projects based on distutils python setup.py install --record=/path/to/record_file # projects based on setuptools python setup.py install --record=/path/to/record_file --single-version-externally-managed" This works and gets the project installed. However, this does not give us PEP 376 compatibility and adds a dependency on distribute/setuptools. Another side effect from the methods above, the RECORD file does not end up in the right place. I am sure we can fix this, but do we really want to? To get everything working it seems we will have to do a custom distribute/setuptools install similar to how pip does things. https://github.com/pypa/pip/blob/master/pip/req.py#L540 Note, we do not have the above issue with packaging (setup.cfg) based projects. At this point it seems we need to pick one of three options: 1. Only support packaging based projects (setup.cfg) 2. Only support packaging and distutils based projects, punt on projects that require distribute/setuptools. 3. Support all three, packaging, distutils, and distribute/setuptool based projects. Pros and Cons ============= Option 1 -------- Only support packaging based projects(setup.cfg). Pros * enforce the new standard, setup.cfg and static metadata. * clear project scope; one way forward * no dependencies on 3rd party modules (distribute) * chance to make a clean break; distutils is still in the stdlib and pip supports Python 3 Cons * unable to install most projects day one; will have to defer to 3rd party tools such as pip and distribute Option 2 -------- Only support installing packaging and distutils based projects and punt on projects that require distribute/setuptools. Pros * can install more projects than option 1. * no dependencies on 3rd party modules (distribute) * promote the new standard with a transition for distutils based projects Cons * still supports setup.py * causes confusion; can install some projects with a setup.py and not others * may prolong the move to setup.cfg and static metadata * miss our chance for a clean break Option 3 -------- Support all three, packaging, distutils, and distribute/setuptools based projects. Pros * can install more projects than option 1 and option 2 Cons * WILL prolong the move to setup.cfg and static metadata. Most people will continue to use what they know best. * miss our chance for a clean break I am leaning toward Option 1 myself, as option 2 will only cause confusion. Option 3 seems like going backward by requiring distribute and will prolong the move to setup.cfg and static metadata. Going with option 1 will require a lot of effort to get the community on board and start converting to a valid setup.cfg, or providing support for both, a valid setup.cfg and setup.py. With packaging and pysetup being new tools we should keep them clean and focused on the future. This is especially true when good alternatives exist to provide a transition strategy for most projects. Thoughts?