I propose an extension to PEP 376 to support the development of projects such that: - Installation tools should expect to need to cope with files present in purelib named "foo.dist-link". Each of these files will be of the form "/path/containing/foo.dist-info\nreldir" For example, the contents of such a file might be: /home/chrism/projects/zope.interface src Presence of such files would indicate a link to a directory which contains a .dist-info directory for the project as well as the subdirectory in the project which actually contains packages and modules. - Installation tools should need to cope with a "develop.pth" file in purelib. Its presence will indicate that there are projects in development mode in this environment. Its absence indicates that there are no projects in development mode in this environment. - Installer tools should place dist-link files into purelib as the result of a notional "develop" command e.g. pysetup develop . If "pysetup develop ." were run in zope.interface, zope.interface.dist-link would be installed into purelib - Installer tools should mutate "develop.pth" as the result of "develop", e.g. "pysetup develop ." would create this file if it didn't already exist. After a "pysetup develop" of zope.interface it might look like: import pkgutil.develop; pkgutil.develop.save_path_order() /home/chrism/projects/zope.interface/src import pkgutil.develop; pkgutil.develop.reorder_sys_path() The "import" lines would ensure that the paths mentioned in the .pth file would precede stdlib sys.paths but would come after paths mentioned on PYTHONPATH envvar. Some sort of hack like this anyway; maybe Python could offer better support for this without hackiness of relying on executing code via a .pth file at startup time. - "pysetup undevelop ." of zope.interface would undo the changes made via "pysetup develop"; it would also remove develop.pth if no other developed projects existed anymore after zope.interface was undeveloped. - It will be permissible to have both the "develop" version and the "install" version of a library installed in the same purelib. Installer tools should be able to cope with this and display both versions when they are asked to list installed distributions. That's the basics.