Dan Rose

Thanks for the ping. The coverage dip is due to the xfail on `test_re_identify_python_if_different_python_package`. That's the downside of breaking this up into two PRs.

@dirk-thomas Friendly ping.

> @rotu Please rebase this branch in a way that the pull requests only shows commits related to this change. Oops. Nothing like rebasing on the wrong master. Blech. Let...

From what you pointed me to, it sounds like using pth files puts things in the wrong order with respect to overlayed workspaces. I'm not sure I understand from that...

That's only partly true. It seems the --editable flag to setup.py develop allows us to deactivate the code for easy-install.pth (#219), I presume because easy-install is only suitable for packages...

> How is this supposed to work on Windows? What do you mean? If you’re already passing the `—symlink-install` flag, you’re letting Colcon know that the system supports symlinks, no?

This makes no more assumptions about the viability of symlinks than the surrounding code. Currently, we symlink the sources to the build directory immediately prior to calling `setup.py develop`. https://github.com/RoverRobotics-forks/colcon-core/blob/c58a329b06da94f53055c4ba6f01d82171285fda/colcon_core/task/python/build.py#L86

I think we're on the same page. Here are my thoughts: Run `setup.py install` twice, the first time with `--dry-run --single-version-externally-managed --record install.log` and the second time with `--skip-build --single-version-externally-managed...

No, I still imagine builds running asynchronously from each other. If two packages intend to write the same file, the first will find it, and the second will see that...

> How would you distinguish if an already existing file has been installed by a different package or by the same package in a previous build? Say you build package...