Oh-my-posh3: Language only looks for VIRTUAL_ENV if files in current folder, not sub folders (or if it's just generally active)

[rsb177]

Prerequisites

• [x] I have read and understand the CONTRIBUTING guide
• [x] I looked for duplicate issues before submitting this one

Description

I work in python quite a bit. But the way my current company structures it's projects, inside the base project folder, there are no python files, they end up in another folder (like "src" or some other name). Since I tend to run a number of commands from this base folder, it would be nice to still be able to see my virtual environment. I tried just using the envvar segment, but remembered that the VIRTUAL_ENV variable has the whole path. If you're not against it, it would be nice to either always show the env if present, or have that be an option to set in the segment properties. Checking for subfolders could be helpful too, but I'm guessing that could get messy.

Environment

• Oh my Posh version: v3.53.1
• Theme: custom
• Operating System: Win10, MacOS, & Ubuntu
• Shell: bash/pwsh/zsh
• Terminal: Windows Terminal/iTerm2

[meakbiyik]

I missed this issue and opened mine several hours later --sorry about that. Here are my use cases:

1. When I want to start jupyter, or just do some basic scripting by opening the terminal, I would like to know at least which python I am using, e.g base conda or some other conda?

2. When I am writing a package, I always use an environment in the root location (a PEP-compliant dependency management tool called poetry creates this in the root location of the package using virtualenv, with the folder name .venv). I never, or at least very rarely go down inside the module, I just run the package as a module from the upper level, and vscode handles the activation of the environment automatically so I do not need to do anything else. The existence of "pyproject.toml" file is a good indicator that the directory is a python package, if such a thing is needed.

I cannot be sure what's the best way to resolve this, but there are several options: showing the python segment all the time, showing the python segment when an environment is activated (right now, the default python installation also pops up which does not have a name, and tbh it is very rarely used), showing the python segment when an environment that is not noted in the configuration as "default" is activated (this is better than the previous one actually, since for some people the default installation is a conda python which has an environment name all the time, and they can just add "base" to the configuration to not see it, and leaving it empty would work for the nameless case).

As a little follow up, I can also opt for showing the version number of python only when the environment does not have a name -- for example in the case of a default python installation. I think this was the version 2 behavior of ohmyposh?

[JanDeDobbeleer]

@meakbiyik if I get this right, for 2 we could also just look for the .venv folder or pyproject.toml file and display the Python info, right? Is there something similar for Jupyter?

@rsb177 do you have the same setup, as in there is a .venv folder in the root of the project, or a configuration file?

Going through subfolders is discouraged as you'd have to decide how deep to go which will never cover all use-cases. The git segment has this functionality, but it relies on getting the git root folder to decide what to display, maybe relying on what's inside VIRTUAL_ENV can offer something similar.

[rsb177]

I love Poetry. The pyproject.toml in the root would solve that. It stores the venvs in the home folder though. For my company, they just use makefiles and docker containers for everything, so I just create my own venv folder in the project root. The only downside to looking for the venv or .venv folder in the root is you'd be locked into certain names. My preference is definitely to name the venv something related to the project name like Poetry does. Makes it easy to tell you've got the right venv if you're bouncing around between projects a lot.

[meakbiyik]

@JanDeDobbeleer pyproject.toml is getting more and more common as it is recommended by the language itself, but I wouldn't say that it is an absolute standard yet. Also, as @rsb177 points out, virtual environment being inside the package folder is not very common either (there is a flag in Poetry for that which is false by default), and even then the name of such a folder is far from standardized. Here are some examples from a Python .gitignore:

.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/

For Jupyter, there is no requirement whatsoever: you can start the kernel anywhere and just use the web interface to walk around the directories.

Because of these reasons, it makes more sense to me to instead of deciding on when or where to show the Python segment, the approach should be when or where NOT to show the segment. My final recommendation here is based on that.

[JanDeDobbeleer]

I'll need to read through this tomorrow morning as I can't seem to wrap my head around it right now. Drafting a flowchart might make it clear. I'm looking for the most pragmatic solution, as the more logic we have, the slower things can become ;-)

[rsb177]

To make it easy, you could always add an option to always show the venv if the environment variable is set. I know powerline-go just looks for the presence of the environment variable.

[daddycocoaman]

I was about to open an issue for this since I came across the same scenario this morning but glad I caught this thread.

I agree with @rsb177 that just checking for VIRTUAL_ENV is the way to go, since virtualenvs like the ones for Poetry don't necessarily have to be in the same folder as the current directory.

I don't use conda so I can't speak on it to much but @meakbiyik made some good points, and although I don't agree that the segment should be "always on" by default, it could be an option for those that want it. My personal preference is to keep my .venv projects in my package folder to make it easier to find for other programs and extensions that don't fully support Poetry.

[JanDeDobbeleer]

@daddycocoaman always on is available now. This one's next on the list as soon as I get the git improvements out of the door. Not forgotten though.

[JanDeDobbeleer]

The next release has a new display_mode when it comes to the Python segment. context will display the segment when there are files or a virtualenv present. environment will only display when there's a virtual env, regardless of the files in the current folder. files wil only show the segment when files are found in the current folder.

[JanDeDobbeleer]

@daddycocoaman @meakbiyik @rsb177 can you have a look at the latest release/changes?

[daddycocoaman]

@daddycocoaman @meakbiyik @rsb177 can you have a look at the latest release/changes?

Confirmed the modes work as advertised. Thanks for your efforts!

[rsb177]

Looks good! Thanks a ton!!