Add virtualenv support to bobthefish powerbar theme

[stestagg]

If VIRTUAL_ENV envvar is set, then prefix the basename in blue to the start of the powerbar
Also set the VIRTUAL_ENV_DISABLE_PROMPT envvar to stop virtualenv from adding its own prefix

Currently an issue when entering a virtualenv, because the fish script to enter a virtualenv returns non-zero exit status when VIRTUAL_ENV_DISABLE_PROMPT is set, but this is a minor issue that can be solved by virtualenv patch.

[bpinto]

@bobthecow What do you think?

[bobthecow]

Let's use $slate_blue here to keep with the color palette?

[bobthecow]

I don't use virtualenv, but I am not the least bit opposed :)

It does seem like that should go after the flags rather than before, though.

[bobthecow]

This actually shouldn't be inside the __bobthefish_prompt_status function. Each one of those function calls is its own segment.

Let's pull the whole virtualenv logic out into its own function (__bobthefish_prompt_virtualenv?), and call it after __bobthefish_prompt_status (and before __bobthefish_prompt_user) inside fish_prompt at the bottom.

[bpinto]

Thanks for joining the conversation @bobthecow!

[bobthecow]

@bpinto No problem :)

On second thought, I'd put it after the call to __bobthefish_prompt_user — that seems to map well to where it would fit in the hierarchy of the prompt to me.

[bpinto]

@stestagg Are you around?

[bobthecow]

I have a branch on my fork with this plus my changes (but rebased against the current bobthefish).

https://github.com/bobthecow/oh-my-fish/compare/virtualenv

I'm a bit worried about that set -gx VIRTUAL_ENV_DISABLE_PROMPT true, to be honest. I'd really rather not include global changes like that in a prompt theme. Is there another way to make that work? Should we detect when it needs to be set and warn users to add it to their own config instead?

[stestagg]

Sorry for the delayed response from me, I've had other things on.
Personally, I prefer having the virtualenv first in the prompt, but that's personal preference, which starts to be an issue with published prompts like this.

I'm starting to think that powerline functionality should be abstracted so it's simpler to create custom powerlines, but again, separate issue.

as for the global environment, the original pull request: pypa/virtualenv#5 was for this exact reason, to allow someone to have a custom prompt, I'd suggest this is a very safe default behaviour to follow.

Thanks for picking this up, and your changes.

Steve

[bobthecow]

Personally, I prefer having the virtualenv first in the prompt, but that's personal preference, which starts to be an issue with published prompts like this.

If you want to override the order, you could source the original theme then redefine fish_prompt yourself. It's all broken down into nice, neat chunks for you :)

function fish_prompt -d 'bobthefish, a fish theme optimized for awesome'
  set -g RETVAL $status
  __bobthefish_prompt_status
  __bobthefish_prompt_user
  __bobthefish_prompt_virtualenv
  if __bobthefish_in_git
    __bobthefish_prompt_git
  else
    __bobthefish_prompt_dir
  end
  __bobthefish_finish_segments
end

For what it's worth, though, the only thing you'll usually see in front of your virtualenv segment is the ! or % flags.

as for the global environment, the original pull request: pypa/virtualenv#5 was for this exact reason, to allow someone to have a custom prompt, I'd suggest this is a very safe default behaviour to follow.

Fair enough. Is there anything in the environment we can check to see whether someone is actually using virtualenv, so that we don't litter everyone else's global environment with a flag to disable something they're not even using?

[stestagg]

That's a fair point about not seeing the 'user' by default, I hadn't checked back about that..

As for your question about the env var, I don't know how simple this will be.

The virtualenv script that is run is here: https://github.com/pypa/virtualenv/blob/develop/virtualenv_embedded/activate.fish

The problem is that when the activate.fish script is run, it's at script run time that it looks for the $VIRTUAL_ENV_DISABLE_PROMPT environment as a one-off, and then replaces the fish_prompt function with a wrapper func that prints it's virtualenv prefix first.

Once this wrapping happens, it's set until the 'deactivate' function is called to break out of the virtualenv (some time in the future)

The only way I can see to be dynamic about this would be to detect when a virtualenv has just been activated, and replace the fish_prompt function with the original, but that would be quite complex, imo.

There might be a simpler way, but it eludes me right now

[bobthecow]

Given that it's a one-off check, fish_prompt.fish seems like a pretty terrible place to put the $VIRTUAL_ENV_DISABLE_PROMPT flag. It seems like something that belongs at the oh-my-fish level, if not in the user's own configuration.