Closed cderv closed 2 years ago
pyenv-win installs its python versions in C:\Users\Arbaaz\.pyenv\pyenv-win\versions\
and pyenv which python
command checks that directory for the given env.
pyenv-win-venv installs the virtualenvs in C:\Users\Arbaaz\.pyenv-win-venv\envs
so pyenv which python
cannot find the virtualenv in its directory. Adding the virtualenv as a symlink into C:\Users\Arbaaz\.pyenv\pyenv-win\versions\
wont work either as pyenv-win doesnt seem to work like pyenv does.
I can add a pyenv-venv which python
command which can do the same thing you need for your case. Would that fix your issue?
Released a new version which adds the which
command to the CLI.
Changelog: https://github.com/pyenv-win/pyenv-win-venv/releases/tag/v0.5.0
Update using: https://github.com/pyenv-win/pyenv-win-venv#update
Let me know if this fixes the issue.
Thanks. Yes that will fix it. I just need to always use a venv so that I can rely on the path resolution.
Otherwise not really a way to know when to switch to pyenv which
or pyenv-venv which
.
It will work know that I know that, it just still feel a bit odd to me that the pyenv-win-venv
extension (or plugin , not sure of the name) will make a feature of pyenv-win
not working anymore. They both rely on the same file, but not using it the same. I am not yet enough a regular user to know well the workflow. I'll probably ask back again if I encounter some friction in the workflow.
Anyway, thanks for the quick release. Updated and all good.
I just need to always use a venv so that I can rely on the path resolution. Otherwise not really a way to know when to switch to pyenv which or pyenv-venv which
Yea, if an env is not activated, it will show an error that "Executable not found" or should it fallback to pyenv-win and run pyenv which exec
instead so that the globally activated python's exec will be the output?
it just still feel a bit odd to me that the pyenv-win-venv extension (or plugin , not sure of the name) will make a feature of pyenv-win not working anymore. They both rely on the same file, but not using it the same.
The reason for the that is the fact that pyenv-win-venv
is not exactly a plugin/extension for pyenv-win
. It is simply a separate CLI which I created to mimic some of the same functionalities of pyenv-virtualenv which is a plugin for pyenv, the pyenv tool for UNIX systems. It being a proper plugin integrates well with pyenv unlike my own CLI. It also uses virtualenv instead of venv like this CLI so there could be other differences.
I only added the features that I needed for my use case as I was getting a bit frustrated that there wasnt a virtualenv plugin for pyenv-win when I migrated from Linux to Windows so there could be lots of missing features, let me know if you have any other improvements for the CLI.
or should it fallback to pyenv-win and run pyenv which exec instead so that the globally activated python's exec will be the output?
Yes I think I would have expected the default python install found (from pyenv
) if no env is activated. It seems like it would be like that in a Unix ecosytem. The python for venv being used only when activated.
I guess this is probably possible but probably require some changes to be less independant CLI tool, or more integration on pyenv-win
side to know about pyenv-win-venv
virtuals environment.
The reason for the that is the fact that pyenv-win-venv is not exactly a plugin/extension for pyenv-win.
Thanks for the addition on this topic. That makes the context more clear to me. I found your project while looking for using virtual env with pyenv on windows, and pyenv-virtualenv
does not support Windows. I found your project to look at an alternative.
I only added the features that I needed for my use case as I was getting a bit frustrated that there wasnt a virtualenv plugin for pyenv-win when I migrated from Linux to Windows
Thanks a lot for making your work open in a project like this. It is really appreciated. I find it really useful !
I don't know the long term plan for
pyenv-win
but it could make sense to have it like a plugin with onpyenv
command ,pyenv venv
to access the tool here. Like with virtualenv plugin. But that is probably much work.
Two separate CLI seems ok to me and makes sense, I suppose we could try improve the integration between both so that they work without friction. Happy to help on this path anyway.
I'll keep using it and share ideas or proposals.
Yes I think I would have expected the default python install found (from pyenv) if no env is activated. It seems like it would be like that in a Unix ecosytem. The python for venv being used only when activated.
Great. It has been released in v0.5.2
Thanks a lot for making your work open in a project like this. It is really appreciated. I find it really useful !
I am glad that you found it useful. Please continue to suggest other features that you find missing. I will definitely add them when I get the free time. 😄
Two separate CLI seems ok to me and makes sense, I suppose we could try improve the integration between both so that they work without friction.
Definitely. I believe some changes will need to be made to pyenv-win itself to make it recognize pyenv-win-venv as a plugin and make it integrate with the plugin properly. I will look into how it works with the original pyenv sometime soon, that might help with this integration.
Awesome thank you !
It seems pyenv-venv is using the same file than pyenv in a different way. Activating the environment does activate python but do not help with the command.
Is this known to be incompatible ? Should we use only pyenv-venv as sonn as we are using venv ? or should it be considered an issue ? It feels unexpected to me at least.
I found this because I have so code in profile that use
pyenv which python
to get the path of the binary for configuring some tolls using python.