[Stackless] 'Normal' sys.path being used instead of Stackless one

[Richard Tew]

On Mon, Jan 19, 2009 at 10:07 AM, Ben Sizer <kylotan at gmail.com> wrote:
> 2009/1/19 Richard Tew <richard.m.tew at gmail.com>:
>> Where binary builds made for standard Python don't do this, they
>> should be directly usable with Stackless.
>
> This is pretty much the main issue for me. This is not what I'm seeing
> in practice, and I don't know where the fault lies. For example, I try
> to 'import socket' from my embedded Stackless app and it fails to
> import '_socket'. This could be because it's looking in the wrong
> place (as my Stackless build didn't build socket, for some reason),
> but I can see quite clearly that it's looking in my normal Python libs
> directory, where socket is fully built and operational. And if I do it
> from my normal Python install, it seems to work. So, something is
> getting confused along the way, and I guessed - wrongly, it seems? -
> that it might be a binary incompatibility problem. Or a path problem.

I expect this is a problem with your compilation environment.

If a standard part of Python fails to compile, you need to find out
why and make sure it compiles before using the results of this
compilation.  I would be very surprised if socket also compiled with
the source code for the matching version of standard Python using the
same compilation environment.

I've compiled Stackless before and encountered exactly this problem.
Then I've compiled the non-Stackless source code for the same version
of Python and had the same problem.  But, looking at the error and
searching the includes which I have installed, I can't see how Python
could possibly compile its socket module.  I don't have a clear
recollection, but I suspect that I was using Visual C++ Express.

>> But that aside, I don't really understand why you are needing to do this.
>
> Abridged version:
> 1) I didn't feel I could overwrite my standard Python installation
> binaries with the Stackless ones due to apparent compatibility issues;

If there are any outstanding issues you can identify which are
introduced by Stackless itself, rather than standard Python, please
post them to the list.

> 2) I see what appears to be compatibility issues, couldn't find
> documentation confirming or denying this one way or the other, so
> assumed they existed and looked for a workaround;
> 3) I'd appreciate any solution that allows me to (a) use Stackless as
> part of an embedded app and (b) doesn't require that I recompile
> binary 3rd party libraries downloaded from easy_install etc.

When I am building a Stackless installer for a standard Python
version, one of the steps I have to do is get PyWin32 working in the
Stackless build.  What I do is:

1. Install the official release of the standard Python version.
2. Install the PyWin32 build for that official release.
3. Copy the relevant folders out of the C:\Python26\ directory into my
build directories.
4. Build the installer.

It sucks and it's awkward but it beats recompiling and there's no path
dependencies in the copy and paste of binary modules.  Not that it's
directly relevant to your situation.

What I would say though, is that if I were embedding a version of
Python into an application, I'd consider recompiling needs to be part
of the process.  I'd write it into my build scripts.  If
'easy_install' doesn't support this, then it, again, is a general
Python problem.

Cheers,
Richard.