Return to Answer

But, after all, why should virtualenv be active in global gnome-shell context ?

This would surely break all system-level python application installed.

So the only safe way to start a virtualenv application is to start from a terminal shell

Probably it is safer to activate environment in the ~/.bash_profile ~/.zprofile, enabling login-shell option in terminal.

The alternative setting, using ~/.bashrc, should be avoided because it can cause problems in subshells.

So, enable the login-option, start the terminal (or bash/zsh --login in xterm ...), "workon", and the start emacs (server) from the terminal shell.

To run a virtualenv application, a dedicated wrapper script should source activate script before execution.

For a generic wrapper (similar to ruby 'bundle exec' and rvm stuff), see:

• https://gist.github.com/datagrok/2199506

Maybe a 're-hash' is required ...

• https://github.com/pypa/virtualenv/blob/develop/virtualenv_embedded/activate.sh#L76

But, after all, why should virtualenv be active in global gnome-shell context ?

This would surely break all system-level python application installed.

So the only safe way to start a virtualenv application is to start from a terminal shell

Probably it is safer to activate environment in the ~/.bash_profile ~/.zprofile, enabling login-shell option in terminal.

The alternative setting, using ~/.bashrc, should be avoided because it can cause problems in subshells.

So,

• enable the login-option
• start the terminal (or bash/zsh --login in xterm ...)
• "workon"
• then start emacs (server) from the terminal shell.

To run a virtualenv application from gnome-shell, the desktop file must exec a dedicated wrapper script that source env activate before execution.

For a generic wrapper (similar to ruby 'bundle exec' and rvm stuff), see:

• https://gist.github.com/datagrok/2199506

Maybe a 're-hash' is required ...

• https://github.com/pypa/virtualenv/blob/develop/virtualenv_embedded/activate.sh#L76

But, after all, why should virtualenv be active in global gnome-shell context ?

This would surely break all system-level python application installed.

So the only safe way to start a virtualenv application is to start from a terminal shell

Probably it is safer to activate environment in the ~/.bash_profile ~/.zprofile, enabling login-shell option in terminal.

The alternative setting ~/.basrc should be avoided because it can give problems in subshells.

So, enable the login-option, start the terminal (or bash/zsh --login in xterm ...), "workon", and the start emacs (server) from the terminal shell.

To run a virtualenv application, a dedicated wrapper script should source activate script before execution.

For a generic wrapper (similar to ruby 'bundle exec' and rvm stuff), see:

• https://gist.github.com/datagrok/2199506

But, after all, why should virtualenv be active in global gnome-shell context ?

This would surely break all system-level python application installed.

So the only safe way to start a virtualenv application is to start from a terminal shell

Probably it is safer to activate environment in the ~/.bash_profile ~/.zprofile, enabling login-shell option in terminal.

The alternative setting, using ~/.bashrc, should be avoided because it can cause problems in subshells.

So, enable the login-option, start the terminal (or bash/zsh --login in xterm ...), "workon", and the start emacs (server) from the terminal shell.

To run a virtualenv application, a dedicated wrapper script should source activate script before execution.

For a generic wrapper (similar to ruby 'bundle exec' and rvm stuff), see:

• https://gist.github.com/datagrok/2199506

Maybe a 're-hash' is required ...

• https://github.com/pypa/virtualenv/blob/develop/virtualenv_embedded/activate.sh#L76

But, after all, why should virtualenv be active in global gnome-shell context ?

This would surely break all system-level python application installed.

So the only safe way to start a virtualenv application is to start from a terminal shell

Probably it is safer to activate environment in the ~/.bash_profile ~/.zprofile, enabling login-shell option in terminal.

The alternative setting ~/.basrc should be avoided because it can give problems in subshells.

So, enable the login-option, start the terminal (or bash/zsh --login in xterm ...), "workon", and the start emacs (server) from the terminal shell.

But, after all, why should virtualenv be active in global gnome-shell context ?

This would surely break all system-level python application installed.

So the only safe way to start a virtualenv application is to start from a terminal shell

Probably it is safer to activate environment in the ~/.bash_profile ~/.zprofile, enabling login-shell option in terminal.

The alternative setting ~/.basrc should be avoided because it can give problems in subshells.

So, enable the login-option, start the terminal (or bash/zsh --login in xterm ...), "workon", and the start emacs (server) from the terminal shell.

To run a virtualenv application, a dedicated wrapper script should source activate script before execution.

For a generic wrapper (similar to ruby 'bundle exec' and rvm stuff), see:

• https://gist.github.com/datagrok/2199506