[Stackless] stacklesslib & tealet
werner at thieprojects.ch
Wed May 1 12:19:25 CEST 2013
From what I recall, I asked in previous mail if there is a naming
convention in place which would allow to keep stackless apart from stock
installations, like the OSX one.
AFAIR the main swing was for some time, use stackless in lieu of python,
whereas now it seems to be keep things apart.
I'm fine with keeping things apart, no opposition on my side and with a
different naming for the package and the executable we might even pass
the tests for becoming a brew instead of a tap
PS: BTW - homebrew is NOT replacing stock python, it does a separate
install in /usr/local, with the executables name also being 'python',
which means whatever PATH you have set, it either takes the stackless or
the stock one. Eclipse's PyDev does a great job keeping several python's
apart as well as virtualenv
On 4/30/13 8:00 PM, Christian Tismer wrote:
> Hi Werner,
> On 4/30/13 5:32 PM, Werner Thie wrote:
>> Hi all
>> Concerning the Mac OSX version, I still have that brew recipe? As a
>> tap it would probably have a life in the home brew environment.
>> Concerning the problems with several Python version installed on a Mac
>> the home brew approach is by far the cleanest I found.
>> All we need is tarball on the official site with an MD5 digest, form
>> there its only
>> brew install stackless
>> Anyone favoring this approach?
> I saw your post to the list from July 2012. At that time I was not yet
> using Homebrew,
> but meanwhile I am.
> Here my opinion:
> - Homebrew does a quite good job when you need a certain package.
> It is also what I use on OS X, instead of using canned builds from
> - I had a closer look at your version for Stackless, and that is
> exactly what I don't want, with any installer, be it one like
> python.org's, your's, or
> anything else that installs Stackless Python as a replacement of
> regular Python.
> That is not the problem to be solved. We had such solutions since 1998,
> and this was
> the wrong approch, all the time.
> I am meanwhile convinced that it is a bad idea to have an installer for
> Stackless Python
> that replaces CPython by using the same folder and name for the executable.
> Don't be offended, I have no objection if you modify your Homebrew
> Stackless installer
> and name the executable different from Python, so they can co-exist. So
> please feel free to
> try again to get into the Homebrew distro, do exactly what they do for
> Python and Python3,
> but avoid giving it the name Python or Python3.
> I think my answers to two different threads were not clear enough, so I
> should be a bit
> clearer about what is needed.
> The approach that Anselm and me want to push further is a bit more than
> an installer:
> Instead of downloading and installing a different version, the idea is
> to install
> Stackless on top of an existing CPython of an exact version, and install
> the Stackless
> addition as an extension-like add-on, although that is cheating, because
> we still
> need to replace the interpreter.
> For that reason, I also still am in favor of naming the stackless
> interpreter slightly differently,
> although it can and should share as much as possible from the original
> The point is to get people into trying stackless as an alternative,
> without destroying their
> CPython installation. Stackless needs to play nicely, like an extension
> that you can toss if
> it does not fit your needs.
> If you think it makes sense to use homebrew for this, then I'm
> interested to read your
> thoughts. But yet another installer is neither on the problems nor on
> the solutions side
> of what the topic was in the other thread you are referring to.
> I want Stackless to be (almost) as simple as Greenlet to install.
> Cheers -- Chris
>>> To all:
>>> I think we should try to discuss a road map for Stackless, where the
>>> should go in the future.
>>> What is the best way to set up a discussion? Does the stackless list
>>> for that, or is it better to use some Google groups stuff?
>> -1 for Google groups or
>> rather positive
>> +1 for the list, it is more than sufficient for me
>> Stackless mailing list
>> Stackless at stackless.com
More information about the Stackless