New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Language only looks for VIRTUAL_ENV if files in current folder, not sub folders (or if it's just generally active) #239
Comments
I missed this issue and opened mine several hours later --sorry about that. Here are my use cases:
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? |
@meakbiyik if I get this right, for 2 we could also just look for the @rsb177 do you have the same setup, as in there is a 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 |
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. |
@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 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. |
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 ;-) |
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. |
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. |
@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. |
The next release has a new |
@daddycocoaman @meakbiyik @rsb177 can you have a look at the latest release/changes? |
Confirmed the modes work as advertised. Thanks for your efforts! |
Looks good! Thanks a ton!! |
@jgarza9788 |
This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. |
Prerequisites
CONTRIBUTING
guideDescription
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
The text was updated successfully, but these errors were encountered: