Hmm… I did not realize this was the case, but it actually seems to be an implementation detail that leads to a pretty serious bug, because it seems that it is basically just adding the foo/ directory to the python path, which means that it is not correctly excluding packages, so if I have a src like this:
src
└── foo
├── __init__.py
└── bar
└── __init__.py
And my setup looks like this:
setup(
name="foo",
version="0.0.1",
package_dir={"": "src"},
packages=find_packages(where="src", exclude=["foo.bar"]),
)
Then when I do pip install ., python -c "import foo.bar" correctly throws an ImportError, but after pip install -e ., I am able to successfully import foo.bar. I certainly wouldn’t want the standard to prevent any front-ends from fixing this bug, though I don’t want to discount people who need this as part of their workflow.
Perhaps we can have some MAY language, like “frontends may add top-level directories to the python path, even if the result would expose modules that would not be installed by a regular installation process.” Possibly with some moderating should language to urge front-ends to make “editable installs require rebuild to add new modules” the default choice.