[Stackless] 'Normal' sys.path being used instead of Stackless one
kylotan at gmail.com
Mon Jan 19 16:07:51 CET 2009
2009/1/19 Richard Tew <richard.m.tew at gmail.com>:
> Also, when Python is installed on an operating system the DLLs for
> that release version are placed in 'Windows\System32'.
As an aside, I find it a source of some amusement that the Python
people see fit to throw the DLL into System32 but steadfastly refuse
to add the Python directory or its scripts subdirectory to the PATH
environment variable on installation so that Python is actually
practical to use.
> In order to allow Stackless to be
> installable alongside standard Python, we'd have to rename our DLLs.
> This cascades.. what else do we need to change to get a Stackless
> Windows install to be separate?
Yes, it just looks to me like Python itself is a bit antisocial and
not amenable to compartmentalised installations. This is of no
surprise to me, given the other problems Python has playing nicely
with different versions and so on.
> Keep in mind that Stackless is intended to be 100% compatible with
> standard Python.
> 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.
>> For me it becomes a maintenance problem where I have to rebuild every
>> binary library I may use, whether I am using Stackless functionality
>> for a given project or not. With library distribution via easy_install
>> and eggs becoming more common, this becomes more problematic.
> Well, I'm not really the target market for 'easy_install'. Whenever
> I've used it, I have no idea what it is doing. It's like some magic
> shit which is going on and puts something I'm not quite clear on
> somewhere I'm not exactly sure of. I like to know when I install
> something, what goes where.
I guess you're a fan of the traditional ./configure, make, make install then? :)
All easy_install really does is put a library in site-packages, the
same way as pretty much any installer or a typical setup.py might, for
the most part. But if everything is binary compatible as you say, this
should Just Work anyway, and may not be relevant in the end.
> But that aside, I don't really understand why you are needing to do this.
1) I didn't feel I could overwrite my standard Python installation
binaries with the Stackless ones due to apparent compatibility issues;
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.
More information about the Stackless