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

wexpect fails in venv #26

Open
raczben opened this issue Jan 28, 2020 · 8 comments
Open

wexpect fails in venv #26

raczben opened this issue Jan 28, 2020 · 8 comments
Labels
bug Something isn't working

Comments

@raczben
Copy link
Owner

raczben commented Jan 28, 2020

Describe the bug
Wexpect cannot run inside venv. (Note wexpect works inside virtualenv)

To Reproduce
Create...:
python -m venv myvenv

...and activate venv
myvenv\Scripts\activate

Install wexpect:
python -m pip install wexpect

Run any of from wexpect examples:
python examples\hello_wexpect.py

Expected behavior
Not to crash with EOF

Environment:

  • Win10.0.18363 Build 18363
  • Python 3.7.4
  • wexpect version: Doesnt care, wexpect==2.3.6, wexpect==3.1.0
@raczben raczben added the bug Something isn't working label Jan 28, 2020
@raczben
Copy link
Owner Author

raczben commented Jan 28, 2020

The root-casue will be around process launching.
When the host process starts the console process, gets wring pid. the self.conpid is different than ConsoleReader's os.getpid()
Enable logging, to see more details.

Host's self.conpid matches with ConsoleReader's os.getpid() if wexpect not runs from venv.

@raczben
Copy link
Owner Author

raczben commented Apr 18, 2020

This is the root cause.

raczben added a commit that referenced this issue May 31, 2020
The process pid is differs from the host and the child's point of view.
See #26 for more details. This, random generated pipe_file_name, whill solve this issue.
raczben added a commit that referenced this issue May 31, 2020
@akent
Copy link

akent commented Sep 24, 2020

This fix in dev branch seems to work well. Any chance of a new release?

@ddeel
Copy link

ddeel commented Apr 29, 2021

It looks like this Issue has also turned into a problem for virtualenv...

I ran into a situation where wexpect programs that worked well on a system with an older virtualenv environment do NOT work on systems with newer virtualenv environments. In the newer virtualenv environments, wexpect programs always fail with the same pywintypes.error that says 'The system cannot find the file specified.'

After some debugging, I discovered that wexpect programs still work correctly on all my systems if virtualenv is not used. (But this is not very desirable for me.)

Looking at the virtualenv changelog, I found a note on Release 20.0.34 that says "Align with venv module when creating virtual environments with builtin creator on Windows 3.7 and later"; I'm thinking this means that starting with virtualenv 20.0.34, wexpect no longer works in virtualenv environments, because they'll have the same problem as venv environments.

My current work-around is to simply use virtualenv 20.0.30 for all my wexpect programs. It's not the latest version of virtualenv, but it seems to allow my wexpect programs to continue to work on all my systems, at least for now.

@raczben
Copy link
Owner Author

raczben commented May 3, 2021

Thank this comment,

The 850eece shows a way to solve this issue in all virtualenv. This implementation does not uses the child process' pid to identify the pip.

@wamsachel
Copy link

The 850eece worked for me, thanks!

If anyone needs help, you can use the following cmd inside an activated venv to install the fix:

pip install git+https://github.com/raczben/wexpect.git@dev

allegroai-git pushed a commit to allegroai/clearml-session that referenced this issue Dec 7, 2023
@jgentil
Copy link

jgentil commented Dec 15, 2023

Please release this!

@Stefanhg
Copy link

@jgentil I think the package development is completely dead.
I have done a PR which haven't been merged yet.

My conclusion with this is that it does not always work as if you run multi or single user Python install it still breaks. I think the conclusion was with Python multi user install if you don't run cmd in admin it will install packages in AppData because of write permissions to C:/Program files so therefore it will create 2 Python locations which breaks it.

It sucks as I have some CLI things to test on Windows.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants