Entry points scripts are not isolated

[Overdrivr]

After investigating on strange issues on my module, it seems entry points scripts (defined in packages setup.py) can be called in a different virtualenv than the active one.

Let's say there is a package hello with entry point sayHi

In env A, package is not installed.
In env B, package is installed.

The following steps should reproduce the problem (it seems related to switching virtual envs)

pew workon B
pip install hello
pew workon A
sayHi

sayHi is effectively called.

With env A active, doing the following

python
import distutils.spawn
distutils.spawn.find_executable('hello')

will return the path to the hello package in env B

[berdario]

Ok, this is "by design"

The idea is that you're nesting environments... This could be useful if you have developed something in B that you want to also use in A
obviously the cleaner solution would be to pip install -e /path/to/B/, but that way you'd include all the dependencies of B, which might not be interesting for you if B is a development tool (think something like flake)

Also, if you have sayHi installed in A as well, and you enter first B, then A like in your example, you should find that A's version is shadowing B

Sorry for not replying earlier

[Overdrivr]

In this case, maybe the cli could hint the user that it is using a nested environment. Maybe a small message at the moment the env is activated.

he idea would be to know that with an env already active, activating another does not quit the first one.

What do think ?

[berdario]

Uhm, I always thought it was obvious, since if you use the PS1/prompt integration, when you exit a nested shell you'll still see the name of the outer shell... which admittedly could still be surprising, but only the first time

Anyhow, since I'm already outputting a message in the fork_shell function I applied your suggestion