Skip to content
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

cannot change into environment when using babun ( zsh running on windows) #80

Closed
timeyyy opened this issue Dec 11, 2015 · 14 comments
Closed

Comments

@timeyyy
Copy link

timeyyy commented Dec 11, 2015

Installs and creates successfully using pip.

However i receive this when it finishes creating the env

The system cannot find the path specified.

@timeyyy timeyyy changed the title cannot change into environment ( zsh installed in mintty- terminal emulator for windows) cannot change into environment when using babun ( zsh running on windows) Dec 11, 2015
@timeyyy
Copy link
Author

timeyyy commented Dec 14, 2015

any pointers?

@ryanhiebert
Copy link
Contributor

Perhaps a full log will give better insight. I'm not as familiar with zsh, but I'll see if a log gives me any clues.

@timeyyy
Copy link
Author

timeyyy commented Dec 14, 2015

pew logs? Where would i find a log?

@ryanhiebert
Copy link
Contributor

Sorry, I just meant for you to run the command that is failing, and copy-paste the whole session so that I can see it.

@timeyyy
Copy link
Author

timeyyy commented Dec 14, 2015

pew new tester

Using base prefix 'c:\\python35'
New python executable in tester\Scripts\python.exe
Installing setuptools, pip, wheel...done.
The system cannot find the path specified.

pew workon tester

The system cannot find the path specified.

@ryanhiebert
Copy link
Contributor

Blast. I was hoping it would tell me which path it didn't find.

@berdario
Copy link
Collaborator

Uhm, that seems a Windows error message (due to CreateProcess).

(Again, I procrastinated dealing with the last few issues :/ I'll try to deal with this by the end of the week for real this time)

Thank you for the bug report! and sorry for the inconvenience

@timeyyy
Copy link
Author

timeyyy commented Dec 14, 2015

I can help out if you need, i couldn't find a CreateProcess function though

@berdario
Copy link
Collaborator

berdario commented Jan 1, 2016

Ok, I felt really bad by neglecting these issues, and every time that I thought about it, that idea pushed me away from going back to work on pew once again :/

Now I finally booted into windows to dig into this issue.

Good news: pew has worked inside babun all along.

Bad news: this applies only to a python installed inside cygwin.

This is the CreateProcess I was talking about. Python's subprocess uses popen on posix systems, and CreateProcess on windows. So what I meant earlier is that the error was due to a subprocess.call or subprocess.check_call, and the error message was Windows specific.

Basically, the problem you've found is because SHELL is set to /bin/zsh, but CreateProcess is unable to find /bin/zsh (obviously, since that's not a valid Windows path)

You can work around it with env SHELL=zsh pew workon envname or pew in envname zsh

But then you'll stumble another error... pew will use sys.executable (that is the path of the Python interpreter itself). The problem now is the opposite: this is a Windows path and it'll be supplied as an argument to SHELL (zsh in this case) which doesn't treat \ as the file separator.

I tried to make a simple conversion with Path(sys.executable).as_posix() but this will yield C:/yada/yada which won't still be accepted by zsh due to the leading drive specifier.

You can see the difference in behavior between the 2 pythons here:

{ ~ }  » /usr/bin/python                                                                        ~
Python 2.7.8 (default, Jul 28 2014, 01:34:03)
[GCC 4.8.3] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.sep
'/'
>>> from subprocess import call
>>> call(['/bin/zsh', '-c', 'echo 1'])
1
0
>>> exit()
[1]    6228 abort (core dumped)  /usr/bin/python
{ ~ }  » /cygdrive/c/tools/python2/python -i                                                ~ 134
Python 2.7.8 (default, Jun 30 2014, 16:03:49) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.path.sep
'\\'
>>> from subprocess import call
>>> call(['/bin/zsh'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\tools\python2\lib\subprocess.py", line 522, in call
    return Popen(*popenargs, **kwargs).wait()
  File "C:\tools\python2\lib\subprocess.py", line 710, in __init__
    errread, errwrite)
  File "C:\tools\python2\lib\subprocess.py", line 958, in _execute_child
    startupinfo)
WindowsError: [Error 2] The system cannot find the file specified

Maybe that could be fixed with something like what mingw is doing. Furthermore, I think that if you don't actually need the whole Posix API, but you only want an unix-like shell, mingw is a simpler solution.

Another solution could be to change the way the the shell_check is done, but I don't like the idea of making more code that is shell-specific. At the same time, I don't feel like adding kludges to fix this, guessing the correct format for the path that we're dealing with, etc.

Especially when pew is already working correctly on a normal Windows environment and a Python installed on that environment, and on a Posix environment and a Python installed on that environment.

So, what you might want to do is install pew inside cygwin.
Since cygwin only currently ships the old (and insecure) python 2.7.8, and Urllib3 complains about it, you might want to install Python3. You also need pip (actually, just an updated setuptools) at least until I won't have relaxed the setuptools requirement in pythonz-bd

(I used the full path for the binaries to avoid ambiguities, since on my system I already have the normal Windows Python and pip inside $env:PATH)

pact install python3-setuptools
/usr/bin/easy_install-3.4 pip
/usr/bin/pip3 install pew

and voila (you might need to rebaseall your cygwin, if you'll stumble on some address space needed by 'whatever.dll' (0x960000) is already occupied error)

{ ~ }  » pew mktmpenv                                                                           ~
Using base prefix '/usr'
New python executable in c0e65e69b81490/bin/python3.4m
Also creating executable in c0e65e69b81490/bin/python
Installing setuptools, pip, wheel...done.
This is a temporary environment. It will be deleted when you exit
Launching subshell in virtual environment. Type 'exit' or 'Ctrl+D' to return.
{ ~ }  » which python                                                                           ~
/home/Dario/.local/share/virtualenvs/c0e65e69b81490/bin/python
{ ~ }  »                                                                                        ~
{ ~ }  » which python                                                                           ~
/usr/bin/python
{ ~ }  » echo $0                                                                              ~ 1
-zsh

I'll leave this issue open for now, in case there'll be another idea... otherwise I'll just document these steps for installing pew inside cygwin.

@timeyyy
Copy link
Author

timeyyy commented Jan 1, 2016

Ill try installing pew in babun and report if I have any difficultie. if all goes well we can close this and ill make a pull request for the troubleshooting section

@berdario
Copy link
Collaborator

Hi @timeyyy

did you get it to work inside babun?

I now updated the README, but if there's something else that can be fixed, please tell me

@timeyyy
Copy link
Author

timeyyy commented Jan 21, 2016

In a fresh babun

We got a step futher, but i guess i have to setup some more stuff

New python executable in /cygdrive/c/Users/timeyyy/.local/share/virtualenvs/test/bin/python2.7
Not overwriting existing python script /cygdrive/c/Users/timeyyy/.local/share/virtualenvs/test/bin/python (you must use /cygdrive/c/Users/timeyyy/.local/share/virtualenvs/test/bin/python2.7)
Installing setuptools, pip, wheel...done.
ERROR: The virtualenv hasn't been activated correctly.
Either the env is corrupted (try running `pew restore env`),
Or an upgrade of your Python version broke your env,
Or check the contents of your $PATH. You might be adding new directories to it
from inside your shell's configuration file.

In this case, for further details please see: https://github.com/berdario/pew#the-environment-doesnt-seem-to-be-activated

trying restore env

pew restore env      /cygdrive/c/Users/timeyyy/Documents/git/esky/esky/tests 127
Traceback (most recent call last):
  File "/usr/bin/pew", line 11, in <module>
    sys.exit(pew())
  File "/usr/lib/python2.7/site-packages/pew/pew.py", line 684, in pew
    return command(sys.argv[2:])
  File "/usr/lib/python2.7/site-packages/pew/pew.py", line 585, in restore_cmd
    exact_py = py.resolve().name
  File "/usr/lib/python2.7/site-packages/pathlib.py", line 1034, in resolve
    s = self._flavour.resolve(self)
  File "/usr/lib/python2.7/site-packages/pathlib.py", line 320, in resolve
    return _resolve(base, str(path)) or sep
  File "/usr/lib/python2.7/site-packages/pathlib.py", line 305, in _resolve
    target = accessor.readlink(newpath)
  File "/usr/lib/python2.7/site-packages/pathlib.py", line 398, in readlink
    return os.readlink(path)
OSError: [Errno 2] No such file or directory: '/cygdrive/c/Users/timeyyy/Documents/git/esky/esky/tests/C:'

@berdario
Copy link
Collaborator

Uhm, I see that you're using python2 (apparently the cygwin guys are now shipping an updated version: 2.7.10, which is good)

I wonder if the second error you got might be due to an incompatibility with cygwin of the backported pathlib.

I tried to run the restore command, and I don't get that error, even with a non-existing env, it'll try to readlink /home/Dario/.local/share/virtualenvs/test as expected.

A path that ends in /C: seems definitely suspicious. Do you get the same error if you install pew on Python3?

Unfortunately, I never use cygwin... I rebooted into windows just to try this out, ohmyzsh got updated, but now almost nothing works:

both pip and virtualenv fail due to stuff like resource temporarily unavailable while forking, and the problem persists even after running rebaseall, so trying to debug issues on cygwin is impossible for me

@timeyyy
Copy link
Author

timeyyy commented Jan 26, 2016

python3 gave resource errors like you mentioned.

I looked around and it seems virtualenvwrapper and so on don't play so nicely with crygwin so i might explore those avenues when i get some time. In the meantime ill try mingw. Thanks for all the help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants