-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Add Poetry support to virtualenv #2450
base: master
Are you sure you want to change the base?
Conversation
Heavily based on romkatv#1994. Integrate Poetry virtualenv detection into the existing virtualenv segment. For poetry virtualenvs, use the package name as reported by `poetry version`.
Added for debugging purposes.
Don't use echo, instead set a variable which the calling function checks. This is the standard in p10, presumably because it's faster..?
Make them a little less ambiguous.
We were comparing virtualenv's name to pyenv's version, which would never be the same. Now this setting works as intended, although I'm not sure how useful it is. It's probably more useful to reorder this logic so virtualenv has precedence.
Pre-Poetry support, we only entered this codepath when we were inside a virtualenv. Now we enter it for every directory, but we don't want to display an empty segment for non-virtualenv locations.
_virtualenv_name='' | ||
if [[ -n $VIRTUAL_ENV ]]; then | ||
_virtualenv_load_name_VIRTUAL_ENV | ||
else | ||
local start end | ||
_p9k_upglob pyproject.toml | ||
local idx=$? | ||
if (( idx > 0 )); then | ||
_virtualenv_load_name_poetry $idx | ||
fi | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice if this code had the structure
_virtualenv_name=''
if in_virtual_env; then
load_name_from_env_vars
elif in_poetry_project; then
load_poetry_project_name
fi
The current structure is functionally the same, but harder to reason about.
Here's an alternate implementation. I'm not sure if it's better or worse, what do you think?
_virtualenv_load_name_from_env_vars || _virtualenv_load_name_from_poetry || _virtualenv_name=''
_virtualenv_load_name_from_env_vars() {
[[ -z ${VIRTUAL_ENV} ]] && return 1
_virtualenv_name=${VIRTUAL_ENV}
}
_virtualenv_load_name_from_poetry() {
_p9k_upglob pyproject.toml || return 1
_p9k_cached_cmd 0 "$pyproject" poetry -C "$dir" version
_virtualenv_name="${_p9k__ret%% *}"
}
Or do you have a better idea?
Future improvement. Currently there's logic to show virtualenv segment if the current Python version differs from pyenv's. Personally I would like the opposite: show pyenv only if there's no active virtualenv. |
#1994 (comment) applies here as well. I'll keep the PR open in case I do find time to learn poetry and implement support for it in powerlevel10k. At that point your changes might be useful. |
Sure, thanks. Is there anything I can do to help? 🙏
…On Sun, 15 Oct 2023, 4:09 pm Roman Perepelitsa, ***@***.***> wrote:
#1994 (comment)
<#1994 (comment)>
applies here as well.
I'll keep the PR open in case I do find time to learn poetry and implement
support for it in powerlevel10k. At that point your changes might be useful.
—
Reply to this email directly, view it on GitHub
<#2450 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAC4U5L4WBWH6K67YVDIFRTX7OKZZAVCNFSM6AAAAAA55BLJMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRTGMYTGNZRG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Either I need to learn poetry and implement support for it in powerlevel10k (this is how I've developed all other prompt segments), or someone needs to send a PR that I can merge with no changes. The latter can happen not only when the PR is 100% correct in terms of functionality and style, but also when it's obvious to me that it is indeed 100% correct (not an easy thing to achieve given that I never used poetry and don't know what it does). You have two options that don't rely on me:
(1) will be easier for you to maintain. |
Thanks for the info. Just to clarify what you mean by "custom segment". Do
you mean creating a new segment called e.g. "poetry" which I submit as a
pull request?
If so, I'll rework this PR so that the `virtualenv` segment is left as-is,
and create a new segment which contains support for virtualenv, pyenv, and
poetry. Thanks!
…On Mon, 16 Oct 2023 at 19:11, Roman Perepelitsa ***@***.***> wrote:
Sure, thanks. Is there anything I can do to help? 🙏
Either I need to learn poetry and implement support for it in
powerlevel10k (this is how I've developed all other prompt segments), or
someone needs to send a PR that I can merge with no changes. The latter can
happen not only when the PR is 100% correct in terms of functionality and
style, but also when it's obvious to me that it is indeed 100% correct (not
an easy thing to achieve given that I never used poetry and don't know what
it does).
You have two options that don't rely on me:
1. Implement the segment you need as a custom segment.
2. Fork powerlevel10k and implement your changes invasively.
(1) will be easier for you to maintain.
—
Reply to this email directly, view it on GitHub
<#2450 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAC4U5NUPKDEZ6QD5OV76HDX7UI5LAVCNFSM6AAAAAA55BLJMCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUGI2DEMJWGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
I won't merge a PR unless it's obviously correct and matches the style of the surrounding code perfectly. This is a ridiculously high bar. In practice this means that a non-trivial PR has virtually no chance of getting merged. This is why I suggested that instead of sending PRs you implement a custom prompt segment for yourself using the public and documented API provided by powerlevel10k. See |
Got it. I'll leave this PR as-is and use something custom locally 👌 |
@alexjurkiewicz if you want to benefit from the current I use this approach for python project compatibility and full isolation, although of course that is my opinion :). You can achieve what I mentioned above by either setting an export POETRY_VIRTUALENVS_IN_PROJECT=true or by having poetry global config in your virtualenvs.in-project = true
virtualenvs.prefer-active-python = true
virtualenvs.options.always-copy = true Then you can activate your virtual environment and it will be display the right information: $ source .venv/bin/activate or $ poetry shell Check the Poetry Official Documentation for more. I hope that helps. |
Thanks for posting this tip! |
Integrate Poetry virtualenv detection into the existing virtualenv segment. For poetry virtualenvs, use the package name as reported by
poetry version
.Fixes #1994.
This PR isn't working quite right. I'll add review comments where I need help from someone more experience 🙏