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

[Richard Tew]

On Sun, Jan 18, 2009 at 11:17 AM, Ben Sizer <kylotan at gmail.com> wrote:
> 2009/1/18 Richard Tew <richard.m.tew at gmail.com>:
>> Probably.  This is a standard Python thing, Stackless can only be
>> installed as the Python installation of a given version, it can't run
>> cleanly side-by-side and this is not going to change.
>
> May I ask why? Is it that this has been looked into before and found
> to be difficult? Or just that there's no interest in such a thing?

Initially, I assumed it was the way I was going to be making the
installers, where you could have both the standard Python version and
the same Stackless version installed at the same time.  But it didn't
take me long to come to the belieft that this approach has no
compelling benefits to offer.

Note that it takes 4-10 hours to build a Windows installer for any
given Python version.  And that's using the existing installer
building mechanisms with the simplest modifications which get it to
work for Stackless.

Also, when Python is installed on an operating system the DLLs for
that release version are placed in 'Windows\System32'.  You can't have
simultaneous variants of a Python release version installed, like rc1,
rc2 and the final release itself.  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?

Let's assume we have infinite time to experiment and we make a version
of Stackless which installs as something other than Python.  Now we
need to build our own custom installers for every Windows Python
package, as they won't install into the Stackless installation, not
recognising it as Python.

Keep in mind that Stackless is intended to be 100% compatible with
standard Python.

If you don't use the Stackless functionality, then it should behave
exactly the same.  Sure there are some packages which touch the Python
API in non-standard ways and this conflicts with similar non-standard
touching that Stackless does, because when you both take those
liberties, they aren't compatible with each other (SIP and PyQT I am
looking at you..) but this isn't a real problem.

Where binary builds made for standard Python don't do this, they
should be directly usable with Stackless.

> 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.

But that aside, I don't really understand why you are needing to do this.

Cheers,
Richard.