On Sun, Jan 18, 2009 at 11:17 AM, Ben Sizer <[email protected]> wrote: > 2009/1/18 Richard Tew <[email protected]>: >> 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. _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
