cygwin + windows python
Cliff
of Python, even though the cygwin python should be my natural choice,
as a lot of the libraries that I use do not work with the cygwin
pytonehon.
I have attempted to use virtualenvwrapper, but don't seem to be able
to get it working under my setup. I am guessing a lot of python
developers using windows would be using the same setup as mine.
I am interested in either find if anyone has already solved the
problem or contribute to make it work.
Cliff
Doug Hellmann
Can you be more specific about the problem you're encountering? I haven't tried to use the configuration you describe, but the error message may point to a configuration error or a bug we can fix.
Doug
Waylan Limberg
`bin` dir not existing or something of the sort.
If you're using a windows python binary, then the bin directory is
`Scripts`. The virtualenv lib gets this right and uses the correct dir
for your system. However, virtualenvwrapper will get confused in a
windows system because the assumption is that the dir is `bin` which
doesn't exist after virtualenv creates the env.
When you are using virtualenv alone with no wrappers (and on a native
system) its behavior makes sense. I'm not convinced it does the right
thing in these half-linux/half-windows environments. I'm also not sure
what a better behavior would be. But that's an issue for virtualenv
not virtualenvwrapper.
That said, if virtualenvwrapper checked what virtualenv was using for
its bin dir, that would alleviate much of the problem. I've been
meaning to work up a patch for this myself, but haven't made the time
for it. That and it wouldn't help in my MSYS/MinGW environment as
virtualenv needs to be patched also.
--
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg
Waylan Limberg
have to see if this works for me now. Not sure about Cliff's problem.
Doug Hellmann
Cliff
cygwin has it's own specific type of file path. In Windows, if you
have a directory "C:\Python\26", cygwin translates it into this format
"/cygdrive/c/Python/26", which works well for bash but not for
Python.
For example, you can do:
1. source /cygdrive/c/Python/26/Scripts/virtualenvwrapper.sh
2. /cygdrive/c/Python/26/python.exe -c "import sys"
However, you cannot do:
/cygdrive/c/Python/26/python.exe /cygdrive/c/foo/bar.py
This is basically because cygwin invokes Windows Python to run a
script, and Windows Python expects a Windows type of file path, which
in this case would be "C:\foo\bar.py".
cgwin is shipped with a cygpath command, which does the conversion
between cygwin and windows styles. To run the above command, I would
normally do this way:
/cygdrive/c/Python/26/python.exe $(cygpath -w /cygdrive/c/foo/bar.py)
Most often, /cygdrive/c/foo/bar.py is a variable, and using cygpath -w
$VAR just makes sure a windows style path is supplied to the python
executable .
The problems that I came across using this configuration (cygwin +
windows python) are mainly caused by the handling of cygwin style
path. To make it work, I guess the get_path() function in
user_scripts.py (https://bitbucket.org/dhellmann/virtualenvwrapper/src/
5f79df0dd6bd/virtualenvwrapper/user_scripts.py#cl-247) is the place
where changes can be put into.
Another thing needs to change is in the virtualenvwrapper.sh script
(https://bitbucket.org/dhellmann/virtualenvwrapper/src/5f79df0dd6bd/
virtualenvwrapper.sh#cl-61). The VIRTUALENVWRAPPER_ENV_BIN_DIR needs
to be "Scripts" same as for MSYS.
virtualenvwrapp is already coping with MSYS. I assume that is also
using Windows Python, given that executables are in the "Scripts"
directory. If so, I guess it won't be a big effort to adapt it for
cygwin.
Cliff
Doug Hellmann
Possibly not, although from what you said earlier in this thread I have the impression that if you were using a version of Python inside cygwin, it would already work. Is that right? The problem is mixing a cygwin shell and non-cygwin python? If so, we would need some sort of way to detect the different cases and set up the paths correctly in each.
Doug
Cliff
Yes, it already works for Cygwin + Cygwin Python with no problem. I do
not mean to make any change to that configuration. All I want to do is
to make it work for Cygwin + Windows Python. There is no gain to make
this work while breaks it for Cygwin + Cygwin Python
As far as I am aware, if you have to run Windows Python, Cygwin is the
best platform to give you the leverage of Linux including both shell
scripting and various other utilities not otherwise available to
Windows. MSYS/MinGW is an equivalent of Cygwin but with different
design goals. It's probably better for compiling things, but Cygwin is
far more capable. In fact, being able to have its own build of Python
is a good example of that.
One thing I have not get my head around is that when virtualenvwrapper
is run on MSYS, how are the activate script is handled. Since it's
Windows Python the activate script is a bat file, which cannot be
sourced, but I cannot see how this is reflected.
Doug Hellmann
OK, that's what I understood you to be saying, but I wanted to make sure.
> As far as I am aware, if you have to run Windows Python, Cygwin is the
> best platform to give you the leverage of Linux including both shell
> scripting and various other utilities not otherwise available to
> Windows. MSYS/MinGW is an equivalent of Cygwin but with different
> design goals. It's probably better for compiling things, but Cygwin is
> far more capable. In fact, being able to have its own build of Python
> is a good example of that.
>
> One thing I have not get my head around is that when virtualenvwrapper
> is run on MSYS, how are the activate script is handled. Since it's
> Windows Python the activate script is a bat file, which cannot be
> sourced, but I cannot see how this is reflected.
This is the changeset that added MSYS support to virtualenvwrapper:
https://bitbucket.org/dhellmann/virtualenvwrapper/changeset/77fe16b39aa2
I see changes to the path where it looks for activate.bat, but I don't see anything changing how it sources the file. I accepted the patches on good faith, but don't have any way to test them easily.
Doug
Cliff
does not run the activate.bat file. This is probably the right
behaviour. activate.bat is meant for the DOS shell and does not really
do anything useful on Cygwin. I'm guessing it's the same for MSYS.
On Cygiwn, the activate script for POSIX works quite well in fact,
however, virtualenv does not create it for Windows Python. I need to
manually make one. I suspect the same problem exists on MSYS.
I have managed to get my tweaks working. I will put it to bitbucket
later. How do I run the regression test? Also I'd like to write some
new tests to cover my change, too.
Cliff
Cliff
https://github.com/pypa/virtualenv/pull/107
If what it says is correct, virtualenv does create activate.sh script
for Cygwin as well as MSYS/MinGW. That's really good then. Puzzle
solved! Going to upgrade my virtualenv and test it.
Doug Hellmann
On Aug 26, 2011, at 5:52 PM, Cliff wrote:
>
> My mercurial repo (clone from bitbucket) does include this patch. It
> does not run the activate.bat file. This is probably the right
> behaviour. activate.bat is meant for the DOS shell and does not really
> do anything useful on Cygwin. I'm guessing it's the same for MSYS.
>
> On Cygiwn, the activate script for POSIX works quite well in fact,
> however, virtualenv does not create it for Windows Python. I need to
> manually make one. I suspect the same problem exists on MSYS.
>
> I have managed to get my tweaks working. I will put it to bitbucket
> later. How do I run the regression test? Also I'd like to write some
> new tests to cover my change, too.
Cool!
There are instructions for running the existing tests in the documentation at http://www.doughellmann.com/docs/virtualenvwrapper/developers.html#running-tests.
Doug
Cliff
yet. Will work on it again when I get a chance. Have been using my
forked version on Cygwin, Linux and Mac in the past few weeks. Really
delighted about it.
I also worked together with greghaskins@github on a patch for
virtualenv, where there is a bug in the logic of checking whether the
platform is Cygwin. To get my forked version working, this patch is
needed https://github.com/pypa/virtualenv/pull/107 I guess I'll have
to wait until the patch is accepted by virtualenv trunk. Then I will
submit a pull request to virtualenvwrapper.
My forked version can be found here if anyone is interested in trying
it out:
https://bitbucket.org/cliffxuan/virtualenvwrapper-for-cygwin-windows-python
Apologies that I did not do the "fork" from bitbucket. I'd like to
register it though, but not sure if there is a way to do it.
By the way, I can translate the doc into Chinese if you like.
>
> Doug
Doug Hellmann
On Sep 16, 2011, at 5:15 PM, Cliff wrote:
> I've been busy for a while and have not been able to create the tests
> yet. Will work on it again when I get a chance. Have been using my
> forked version on Cygwin, Linux and Mac in the past few weeks. Really
> delighted about it.
>
> I also worked together with greghaskins@github on a patch for
> virtualenv, where there is a bug in the logic of checking whether the
> platform is Cygwin. To get my forked version working, this patch is
> needed https://github.com/pypa/virtualenv/pull/107 I guess I'll have
> to wait until the patch is accepted by virtualenv trunk. Then I will
> submit a pull request to virtualenvwrapper.
Will we need additional changes in the wrappers for this, or do you mean the general cygwin porting work?
> My forked version can be found here if anyone is interested in trying
> it out:
> https://bitbucket.org/cliffxuan/virtualenvwrapper-for-cygwin-windows-python
>
> Apologies that I did not do the "fork" from bitbucket. I'd like to
> register it though, but not sure if there is a way to do it.
I don't know if there's an easy way to do it, short of making a new fork and then merging your existing changesets into it.
> By the way, I can translate the doc into Chinese if you like.
That would be really cool! Please do that work in a different fork, so it isn't tied to the Cygwin-related changes.
Thanks!
Doug