pyvenv

pyvenv copied to clipboard

pyvenv-workon results in all buffers showing the current virtual environment in the modline. This is wrong - most of my buffers have nothing to do with python. Also, this means that all my python buffers must be in the same projects at any given time, which is usually not the case.

An active virtualenv is set by an environment variable configuration, which is necessarily process-global. Even if your buffers have nothing to do with Python, they still have an active virtualenv.

Does that clarify the situation? :-)

I understand what you are saying, but I think Emacs can do better.

1. Even if my Gnus buffers have a virtual env, there is no reason for them to show that in modline
2. setting environment variables is cheap, so switching virtualenv whenever I switch to another buffer is not problematic.

Therefore, my proposal is:

1. have a buffer-local variable pyenv-virtualenv
2. set it only in python buffers
3. show virtualenv in modline only for windows displaying buffers where pyenv-virtualenv is set
4. when displaying a buffer where pyenv-virtualenv is set, check if it is the same as the process environment and reset the latter if they differ.

Even if my Gnus buffers have a virtual env, there is no reason for them to show that in modline

If you run M-x run-python while in your Gnus buffer, the spawned process will have the virtual environment of that gnus buffer.

setting environment variables is cheap, so switching virtualenv whenever I switch to another buffer is not problematic.

Switching virtual environments also involves running hooks, and possibly overwriting user settings.

pyvenv-mode works exactly the same way as the default virtualenv activate scripts: They modify the prompt, no matter whether you are inside a Python project directory or not.

If you feel that behavior is not useful, you will have to write your own virtualenv display mode and simpy not use pyvenv-mode. You do not lose any virtualenv functionality without that mode.

If you run M-x run-python while in your Gnus buffer, the spawned process will have the virtual environment of that gnus buffer.

Who does that? :-) At any rate, this would merely use the most recently activated virtualenv and show that in the mode line (after all, *Python* is a Python buffer).

pyvenv-mode works exactly the same way as the default virtualenv activate scripts: They modify the prompt, no matter whether you are inside a Python project directory or not.

You view a shell as an analogue of Emacs, and different directories as analogues of buffers. I consider each shell similar to an Emacs buffer, and the Emacs process the analogue of the windowing system or a gnome-terminal (with many tabs).

You view a shell as an analogue of Emacs, and different directories as analogues of buffers. consider each shell similar to an Emacs buffer, and the Emacs process the analogue of the windowing system or a gnome-terminal (with many tabs).

I would love to share your view, but the problem is that environment variables are process-global, and Emacs is a single process. I find that making reality visible to the user is more valuable than trying to simulate an ideal world.

We simply have two views on the issue. Both are valid, just valuing different things more.

consider each shell similar to an Emacs buffer, and the Emacs process the analogue of the windowing system or a gnome-terminal (with many tabs).

I would love to share your view, but the problem is that environment variables are process-global, and Emacs is a single process. I find that making reality visible to the user is more valuable than trying to simulate an ideal world.

As I said, resetting environment is cheap. It only matters when you start a sub-process and those inherit environment from process-environment which can be bound around start-process.

We simply have two views on the issue. Both are valid, just valuing different things more.

Any chance I could win you over?

As I said, resetting environment is cheap.

As I said, changing virtualenvs is not just a matter of resetting environment variables.

It only matters when you start a sub-process and those inherit environment from process-environment which can be bound around start-process.

Which happens a lot. Gnus could, for example, be configured to run a specific mail checker or formatter for a mail you display, which could be written in Python. A lot of things are possible.

You argue in favor of hiding the current state of the system because it's not relevant to you. I argue in favor of showing the current state of the system because your use case is not everyone else's use case.

The beauty of Emacs is that you can configure it to behave the way you want it to, without everyone else having to adapt to your preferences.

Any chance I could win you over?

About as likely as I could "win you over": With good arguments, sure, but right now it looks like we're arguing about taste and personal preferences, and that's difficult to have persuasive arguments about.

The only thing that annoys me a bit is, I always get things like [3.6.7] on the mode line in all (Python and non-Python) buffers...