-
-
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
virtualenv 1.11.6 not working with MSYS2 #650
Comments
To clarify, are you saying that the system Python is built using msys? Or is it a standard python.org build? If the latter, in what sense is msys relevant here? If the Python interpreter is built with msys, then we don't explicitly support that environment. It's effectively a sort of stripped down cygwin environment, but it's not really cygwin. Let's clarify precisely what the environment you're working in is, before jumping to any conclusions, though... |
The system Python is built with MinGW64. Is this supported? Could you give hints where to look/what fails - for some kind of hack? You're right that MSYS doesn't matter in that case, as I can call the virtualenv command from a Windows terminal and still get the same error. I just thought that now that there is a kind of symlink from win7 on (and it is called in the standard way via ln in MSYS), it would be nice not having to copy the whole Python over - as it is e.g. nicely done by virtualenv on Mac |
It sounds to me like the Python build is not identifying sys.prefix correctly, which implies that it's an issue with your Python build rather than a virtualenv issue, and as it's a custom build, it's hard to see how to investigate this further. If you can clarify precisely how the system Python was built, I can see if I can reproduce the build here and investigate further, but that's about all I can think of. |
Thanks for your offer. I think we can get this to work without going back to the build. However, I know not enough about virtualenv internals, so maybe you can support me a bit.
is_msys: detects whether MSYS is present by an environment variable. Now, running a However, when the script tries to install pip and setuptools, following error occurs:
So somehow, it cannot find some standard library modules... |
I'll have a proper look this evening, but my problem here is that if it's a problem with how the Python executable is built, I'd like to know how "official" that Python build is before we bake a workaround into the virtualenv code. If it's something you've built yourself, my instinct is to say you should fix your build. If it's something provided by msys, I'd like to know what usage they support (typically msys tools are not supported for use outside of the msys environment, and the pathname format in your tracebacks makes me think that's not what you're doing. So where precisely did you get your build of Python from? |
Yes. So I'm going to answer this now :)
I think you could get the build options for the Python in question from https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2 For the problem at hand:
doesn't contain Edit: So, with the patch below, I got everything to work. I found it simplest to treat MSYS as Edit2: Changed the detection to whether 'mingw' is in the path to the python executable. A bit better...
|
OK. Thanks for the explanation, I think I see what is going on now. MSYS2 seems to be slightly different from MSYS (which is what I have experience with) in that MSYS is purely intended as a build environment for mingw-based programs, whereas MSYS2 seems to be intended to be more usable as a user environment (which explains why it has Python - that's very much a user tool rather than a build tool). On that basis, MSYS2 python should really be cygwin-based (as the site says, "MSYS2 is a Cygwin-derived Posix-like environment for Windows"). The cygwin builds of Python use a much more Unix-like file layout, which might be better for you :-) Also, virtualenv supports cygwin Python, so the code for that should be a much better fit for what you want. Basically, my view is that the MSYS2 python should be declaring itself as a cygwin-style build. That will likely work much better with virtualenv (and probably other packages as well). I do not think virtualenv should be supporting a third strain of Windows Python build - if the neither standard (win32) nor the cygwin flavours work for you, you (or the MSYS2 project) will probably need to maintain your own patched version of virtualenv. Some specific points on your suggestions: I'm not keen on is_msys being keyed off an environment variable existing. What if I set Although symlinks are available on Windows, they need extra privileges to use them (typically an elevated prompt). So even though symlinks can be used on Windows, they typically shouldn't be. |
OK. With that amount of patching of the Python sources, it's no wonder you're hitting issues with Maybe the msys2 project would develop their own custom patched version of virtualenv, like they have done for Python? |
Yeah, no worries. It seems an edge case. I also wonder whether this Python of use as a reliable development platform, since, as you say, it's patched a lot. In the end, I think the whole path problem is less about MSYS as about a Python built with MinGW64 (which is, in principle, independent of MSYS). E.g. there is mingw-builds which contains Python built with MinGW64 and will probably also not work with virtualenv. Seems like people using this config haven't discovered virtualenv yet. For the sake fo completeness: The fix with the sitecustomize.py is not totally correct, either. If you call virtualenv.exe from cmd.exe it doesn't add the correct site-packages directory to the path, because site.py distinguishes by Ah well :-) Thanks a lot, I got my Frankenstein working. Keep up the nice work. |
This is a pain; having a broken virtualenv breaks Jedi in Emacs. It's a shame that the MSYS2 team patched Python so heavily. |
It took 3 minutes to create the env, it did not complete successful, the size of this incomplete env directory is 301 MB, for some reason it actually contains the entire include path of msys2 toolchain.
|
so this problem is known since 2014 and still exists? Don't allow |
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. |
nice way of removing issues you just don't want to fix, label them stale |
The fix offered by @pe224 on 2014-09-24 still works, I had to modify it for the latest source. The problem is it assumes it's on Windows as Python in msys2 reports as 'win32' while msys2 offers a UNIX-like environment. Once this is taken into account everything works as expected. If there's interest to fix this I can provide a patch. I'm adding this here for anyone in the future who is interested. If there is interest I can provide a proper patch. |
I've opened a new ticket with a patch for v16.0.0 see #1338 |
I'm using the latest version of MSYS2 with Python 2.7.8 as the only system-wide Python.
Pip installed virtualenv 1.11.6 without problems.
Executing
virtualenv myenv
results inSupplying additional arguments like an explicit --python didn't change anything.
Now there seem to be two problems:
First, the virtualenv is not created completely. Parts of myenv/lib are missing and there are no activation scripts.
Second, there is only a non-functioning python in myenv/Scripts/python.exe
Since there is no Python dll, I tried copying around libpython2.7.dll.a and libpython2.7.a, but to no avail. What made the myenv/Scripts/python.exe to work was to symlink the working Python lib/python2.7 to myvenv/lib/python2.7, then it could find the standard library.
Why does the virtualenv creation process stop in the middle? It looks like everything could be brought to work. Also, it seems that whole include/lib folders are copied, although MSYS2 is configured to do native windows symlinks with "ln -s". On my mac, virtualenv creates correct symlinks.
Is it a path issue?
$MSYS_HOME
is correctly set to/c/msys64
What's going on? Thanks for any pointers.
The text was updated successfully, but these errors were encountered: