-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Breakage in --always-copy - fails with: ImportError: No module named time #565
Comments
I'm hitting this issue too, but as a workaround you can add My version information:
Here is the full verbose output on failure:
Here is the full verbose output on success:
|
In both the failing and successful cases the first error line is:
This log isn't useful because I don't have the fullpath to the file it can't find. I hence hacked
It's looking for a |
the same here on Centos7 with stock python 2.7
|
Same here. Using |
the solution is to forget about the --always-copy option on EL based distros |
there seems to be a typo in the fix_lib64 function that is currently running. I correct this and it works as expected. go to line:
replace
Late, but hope this helps |
I'm getting the same problem here as well using CentOS 7.1 with flags |
Same here on Gentoo x86_64 with |
@jdelgad and @selurvedu did you try what i recommended above? |
@ikiini Yes, your patch solves the problem. |
@ikiini It worked! Thank you so much. Now to either get this into RHEL 7 or into the main branch. |
+1 |
great. Sorry for the delayed response..but you're welcome @selurvedu and @jdelgad. |
Only problem seems to be @ikiini 's patch would seem to regress back on #338 which is when it was actually changed from |
Problem still persists with CentOS 7 and python 2.7
|
Ran into a virtualization error that took a while to debug: gratipay/gratipay.com#2327 pypa/virtualenv#565 Ultimate solution: http://stackoverflow.com/questions/24640819/protocol-error-setting-up-virtualenvironment-through-vagrant-on-ubuntu Run console as admin, shared mounts permissions issue. More evidence of issues on Windows: bash script cannot access vagrant shared mount, even when run as root.
@bwilliams42 - Your change indeed fixed the problem for symlink-ing logic. However, things are fundamentally broken when not using --always-copy. Note that copyfile has a "symlink" kwarg that defaults to True. The following logic is effectively, if symlink, call os.symlink, else call copyfile w/o the "symlink" kwarg which results in copyfile defaulting symlink=True and a symlink is created by copyfile. Not useful at all. A symlink is the result no matter what. Shouldn't the patch be something like the following? 1579 if symlink:
1580 os.symlink(lib_dir, lib64_link)
1581 else:
1582 copyfile(lib_dir, lib64_link, symlink=symlink) |
I had an issue whereby I did this and I had a symlink to /usr/lib64. When RH updated some of the openssl libraries this was broken (I was using ansible) with an error stating something like |
Problem still persists on Centos 7.2. This ticket has been reported 2.5 years ago. It seems it's very serious problem. How can I help to fix it? |
Someone needs to provide a working fix. There's one fix that's been proposed here, but it apparently has a couple of problems. I'd suggest starting there. |
BTW, I'm trying to build and pack my python appliction into virtual env on special VM under Vagrant with help of fabric, so it's pretty easy to reproduce this bug with Vagrant + centos box + simple fabric script. I don't have inner knowledge about how virtualenv is supposed to work, so I need some guidance. |
I can't help there sorry, as I'm on Windows, and the whole question of symlinking vs copying (or lib64 directories, which seem involved in this) isn't relevant there. |
…cts fails without this "fix". Also relevant, spotify/dh-virtualenv#150 and numpy/numpy#7570.
Interesting that (I'm on Amazon Linux) when I do |
This issue has been solved about ten years ago. Maybe reconsider using it ? |
@kika Thank you so much. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions. |
This is becoming obsolete with #1366 now in full swing. We'll reopen if someone can still replicate with that. |
On CentOS 6.5 (python2.7 from SCL):
Works fine without it:
The text was updated successfully, but these errors were encountered: