Be more careful with sys.path editing in sitepkgs

[gvanrossum]

The sitepkgs.py script (support for PEP 561) was dropping sys.path[0], but it is also imported by mypy itself, and this broke the typed_ast import when run under Bazel. Bazel puts very few things on sys.path, and sys.path[0] is important -- it has the dependencies. I hope that the editing is only necessary when it's run as an independent script (through subprocess) by the PEP 561 code.

[gvanrossum]

Also, why was this line introduced? It came in #5060 and the comment says # we don't want to pick up mypy.types but I have no idea how that comment relates to #5060. If it was about making tests pass, then something else must have changed, because if I take it out the tests still pass. (Unless it was about test flakes?)

[JelleZijlstra]

I'm not sure of the exact context, but I think without this line Python (presumably 2.7) sometimes imported mypy.types as if it was the standard library types module (which obviously causes things to blow up).

[gvanrossum]

Aha! You're right -- when run as a script, sys.path[0] is the mypy package directory. That makes me confident that this fix is right: it keeps the fix when it's run as a __main__ module, but drops it when imported as a submodule of mypy.

I also just ran the full test suite after completely deleting the fix, and indeed it got some errors in subprocess.

[emmatyping]

Aha! You're right -- when run as a script, sys.path[0] is the mypy package directory. That makes me confident that this fix is right: it keeps the fix when it's run as a main module, but drops it when imported as a submodule of mypy.

Yes that is exactly why this was added. Thank you for adding this, it is probably a good idea bazel aside!