[Stackless] 'Normal' sys.path being used instead of Stackless one
kylotan at gmail.com
Mon Jan 19 17:53:41 CET 2009
2009/1/19 Richard Tew <richard.m.tew at gmail.com>:
> 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
But I don't see the relevance there - if Stackless is using my
pre-installed Python path (it is), and that path contains a pre-built
socket library binary (it does), and Stackless is binary compatible in
all reasonable cases with normal Python (you assure me it is, and I
have no reason to doubt that), then something's surely wrong with the
runtime environment rather than the build environment. Sometimes you
can't build something because you lack the extra libraries for it, but
pre-built binaries for your platform and C runtime should work fine.
> 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.
Perhaps I didn't make myself clear - it's fine for me to rebuild a 3rd
party application that I download with the intention of using it as
part of my C++ program with embedded Stackless. There's an expectation
to recompile things there and the environment is in place to do it, in
theory. My objection was to the perceived need to install Stackless
over the vanilla Python, replacing binaries and libraries etc, and
then being forced to recompile 3rd party libraries as a result. If
that is the case (and you've suggested that it isn't) then it would be
a Stackless issue, as easy_install (or indeed any other binary
installer) supplies the correct version of the library for the
executable/library pair it expects to find in the standard location.
Of course, Python could definitely handle versioning better, and I've
complained about this in the past, but generally the people who know
the most about Python are those the happiest with the status quo so
nothing is likely to change there. Oh well!
More information about the Stackless