Does PyCharm work with the Cygwin Python?

I haven't tried it...have you run into problems using it?

Yes, see below:

Perhaps you are having a similar issue as other tickets.

Can you open your idea.log and see if you are getting a similar message? It might be related to PyCharm sending a Windows-style path when cygwin is expecting a posix path.

OK, I've looked some more into it and here are the results.

1. The error above about python being corrupt corresponds to following exception:

2016-04-25 10:14:57,759 [4711757] INFO - figurations.GeneralCommandLine - Cannot run program "C:\cygwin\bin\python" (in directory "C:\cygwin\bin"): CreateProcess error=5, Access is denied 
java.io.IOException: Cannot run program "C:\cygwin\bin\python" (in directory "C:\cygwin\bin"): CreateProcess error=5, Access is denied
 at java.lang.PocessBuilder.start(ProcessBuilder.java:1048)

This is because python is just a link that isn't meaningful outside cygwin.

2. As the next step, I pointed to the actual file, python-2.7.exe. This allows me to create the Python SDK. Here's how it looks:

Then I added the Python facet to the project and added a hello.py in a source directory. Code completion does not work, it doesn't know about the re module. All that works is syntax highlighting (but this worked even before adding the python SDK)

But most importantly, is this something that's supposed to work? Was anyone successful using the Cygwin Python?

Sorry for the delay, I got an answer from the Powers That Be. cygwin is not considered a supported Python interpreter. Sorry about that!

If I recall correctly, the cygwin folks modify their python distribution that were non-standard and would wreak havok on alternate terminals.

I use Windows python in cygwin and pycharm fine.

This is not really a real issue, this is a laziness on the part of the pycharm developers I think...

I have had some moderate success with the native-to-bash versions of python in cygwin/msys(2), the trick is to make sure it is pointing at the .exe version of python.

The problem is that this requires a lot of manual workaround as the actual support for this is non-existent and the tooling does a lot of incorrect stuff assuming that things are in such and such place with such and such format. Major stuff like virtualenv and pipenv are broken to the point of being everything but unusable (broken skeleton generator, inability to access packaging utilities, no support for debugging).

Hi Sebastian,

There are different feature requests https://youtrack.jetbrains.com/issue/PY-7440, https://youtrack.jetbrains.com/issue/PY-8458. Please vote for them and follow for updates. Feel free to submit another one if you think that something is missing https://youtrack.jetbrains.com/issues/PY.

Sergey,

I have at least found more workaround for IntelliJ's issues and the integration with msys2/mingw/cygwin's version of these on Windows.

I recently decided to checkout the Java JDK source code, I used msys2 hg (not mingw or mingw64) to checkout the sources, worked fine. I tried to point IntelliJ at the hg exe when I opened the project (in C:\msys64\usr\bin\hg ) but it complained it could not CreateProcess the hg exe.

So I wrote a wrapper in C :

#include <stdlib.h>
#include <stdio.h>
#include <process.h>
int main(int argc, char *argv[])
{

    const char exepath[] = "C:\\msys64\\usr\\bin\\python2.exe";
    const char shellpath[] = "C:\\msys64\\usr\\bin\\hg";

    switch (argc) {
      case 2:
        spawnl( _P_WAIT  // flags
               , exepath   // cmd line
               , exepath
               , shellpath   // arg[0] to main (of target)
               , argv[1]
               , NULL    );
        break;
      case 3:
        spawnl( _P_WAIT  // flags
               , exepath   // cmd line
               , exepath
               , shellpath   // arg[0] to main (of target)
               , argv[1]
               , argv[2]
               , NULL    );
        break;
      case 4:
        spawnl( _P_WAIT  // flags
               , exepath   // cmd line
               , exepath
               , shellpath   // arg[0] to main (of target)
               , argv[1]
               , argv[2]
               , argv[3]
               , NULL    );
        break;
      case 5:
        spawnl( _P_WAIT  // flags
               , exepath   // cmd line
               , exepath
               , shellpath   // arg[0] to main (of target)
               , argv[1]
               , argv[2]
               , argv[3]
               , NULL    );
        break;
      case 1:
      case 0:
      default:
        spawnl( _P_WAIT  // flags
               , exepath   // cmd line
               , exepath
               , shellpath // arg[0] to main (of target)
               , NULL    );
        break;
    }

    return 0;
}

Compiled it with mingw64's gcc (not msys2's gcc), and told IntelliJ to use it - voila, it works.

This is what I mean by your windows integration not quite being there, its *almost* there but you just need a tiny bit of work like this to make it smoother.