-
-
Notifications
You must be signed in to change notification settings - Fork 422
Rewrite activate
without using virtualenv/venv/conda's script
#104
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
Conversation
Looks interesting and good. I do not like the setting of |
We need to set |
Rewrite `activate` without using virtualenv/venv/conda's script
I'm running into a problem where pyenv appears to be invoking some scripts in a loop that it can't get out of. If I run either of the following:
It gets into a loop running pyenv scripts over and over again:
Currently on the following: My setup:
shell is bash
Let me know if there's any way I can help debug this. |
Also tried activating my env via the following which failed in the same manner: |
If this helps, the ps output looks like this(repeated over and over):
|
@jimmywan That's bad 😞 If you can use Docket, could you prepare some Dockerfile to reproduce the error in container? It'd help me a lot to dig into the issue.... |
I assume you meant Docker, and not Docket. I will give it a try. |
(Updated with a better script and more detail)
Sample output:
|
@jimmywan Hmm. Thanks for preparing it. I'll give it a try later. |
@jimmywan I confirmed the reproduction. The cause of the issue would be absence of |
The root cause of the problem on absence of |
…table (#104) conda's environment might not have `python` executable. If the prefix doesn't contain `python` in it, `pyenv-which` might be ran into infinite loop if some of `which` hooks invoke `pyenv-virtualenv-prefix`.
@yyuu , thanks for investigating. As a temporary workaround, I could probably add python to my declared dependencies when creating the env. I had already discovered that while using v20151006 I needed to add pip to my dependencies since it would fallback on the non-env pip and install dependencies for miniconda and not test_env, so it wouldn't be that big a deal to add python to that list. |
Confirmed that my docker container now runs without bash processes spiraling out of control, but I'm not entirely sure that everything is working fine. I tried to do some rudimentary testing to reproduce the original problem where a virtualenv was missing python and I managed to hose my virtualenv. I did the following: After I did that, my virtualenv could not be reactivated. Tried to make a slight modification to my test script from before to make this reproducible.
Here is my output (anything starting with a '#' is hand added commentary except for the output of conda env list):
|
@jimmywan |
My apologies, I had misunderstood that the suggested workaround was now required. Adding in python made everything work. I'll adjust my package requirements to include it (arguably should have already been in there). The virtualenv where I had removed python is now "unreachable" since I can't activate it, but I suppose uninstalling python isn't a very reasonable use case. Perhaps a failed python upgrade could cause the same symptoms, but that seems to be a fairly obscure corner case. |
@jimmywan Good to know. Feel free to open an issue or send me some patch if you find sone issue about interoperability with conda! |
This should fix #69. I also aim this as a first step for #103
@blueyed how do you think about this? give me some feedback if you have time.