fix test_typed_pkg test failure on Mac

[JelleZijlstra]

Fixes #4883

The check for whether we're in a venv turns out to be unreliable. See https://stackoverflow.com/questions/1871549/determine-if-python-is-running-inside-virtualenv for background.

Note that if you're testing this on a Mac that previously ran into the bug, you'll have to manually remove any global typedpkg installs for the test to work.

[gvanrossum]

I merged that typeshed PR, but yet another typeshed sync is also needed.

[JelleZijlstra]

I was expecting that we'd just merge this to get mypy master back in a good state. I can send another small PR to remove the type ignore later.

[gvanrossum]

(Actually I propose not to cp that onto the release branch, since the # type: ignore below silences the error. We can fix things on the master branch.)

[gvanrossum]

I'll let @ethanhs review and merge onto master. Once merged I'll cherry-pick this PR into the release-0.590 branch.

[gvanrossum]

(Actually I propose not to cp that onto the release branch, since the # type: ignore below silences the error. We can fix things on the master branch.)

[emmatyping]

LGTM! Thanks for the fix.

[gvanrossum]

So apparently the repro was to run the test *twice*... I'm a little sad this test uses and modifies the environment.

…

On Wed, Apr 11, 2018, 15:10 Ethan Smith ***@***.***> wrote: Merged #4888 <#4888>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4888 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACwrMrAMdQeOyhRBUbrDd9D7EeGWPvziks5tnn86gaJpZM4TQRjl> .

[emmatyping]

So apparently the repro was to run the test twice...

Well, run the test twice in an environment where the global/user site packages directory was available from a virtualenv. In all of my testing environments, the tests could be run twice without failure.

I'm a little sad this test uses and modifies the environment.

Yes, it is less than ideal. I am working on a version that creates, uses, then destroys a virtualenv of its own.

[JelleZijlstra]

I am working on a version that creates, uses, then destroys a virtualenv of its own.

That might also be tricky, because on Python 2 you need to install the third-party virtualenv library to even create a venv, so your test might still need to do things to the global env in order to even make a venv.

[emmatyping]

That might also be tricky, because on Python 2 you need to install the third-party virtualenv library to even create a venv, so your test might still need to do things to the global env in order to even make a venv.

I mean our Python 2 tests already depend on it having typing installed. We can add virtualenv as a requirement on top of that.

[gvanrossum]

I cherry-picked this into release-0.590, but not #4884 (which you created to debug this). And I'm not going to cp the typeshed change for sys.base*prefix, nor hurry with another typeshed sync.