[Stackless] virtualenv idea!

Richard Tew richard.m.tew at gmail.com
Wed Jun 27 03:38:57 CEST 2012


On Wednesday, June 27, 2012, Christian Tismer <tismer at stackless.com> wrote:
> Hi Richard,
>
> (why do you reply in private?)

Accident.
>
> On 26.06.12 21:59, Richard Tew wrote:
>>
>> On Wed, Jun 27, 2012 at 1:16 AM, Christian Tismer <tismer at stackless.com>
wrote:
>>>
>>> Stackless changes the python executable and is therefore not
>>> absolutely easy to install.
>>> This is the reason why the greenlet is preferred so often over
stackless.
>>
>> I would say it was part of the reason.  The other part is that it
>> tends to come as part of a library that enables easy use of
>> asynchronous IO, like gevent or eventlet.
>
> Well, a recurrence. eventlet was probably developed on greenlet because of
> this difficulties.
>>
>> We should also concentrate on doing whatever needs doing on
>> stacklesslib and consider adding that as part of the Stackless
>> distribution.
>
> If you can tell me more on this, that would be great.
> I need to prepare my EuroPython talk where such things
> should be mentioned.

Kristján and I have discussed this in the past.  Like eventlet and gevent,
it offers microthread friendly abstractions for IO.  And monkeypatching
them in place so than existing threading-based code can transparently just
work with the scheduler.

But there's the question, is it better to keep this a pypi hosted and
installable package, or to provide it out of the box as part of the SLP
distribution. Maybe it is not important.

>>
>>> It suddenly struck me that the installation problem might simply
>>> vanish or become invisible?
>>> With virtualenv or maybe some modification, it should be not so hard
>>> to make a stackless installation that creates a virtualenv configuration
>>> that does not impose headaches for newcomers.
>>>
>>> My dream-solution is
>>>
>>>    pip install stackless
>>
>> I think it is definitely a good idea, but it seems complicated.
>>
>> We would be replacing the Python runtime, and injecting some standard
>> library module changes.  If someone is using Python 3.2.1, I don't
>> think it is acceptable to silently give them the Stackless Python
>> 3.2.2 runtime.
>>
> Yes, this needs a bit of thought.
> Actually, we could require a compatible version and otherwise reject
> installation. To ask for the latest update of a python 2.x is probably
> ok. Alternatively, to support 2.x.y where y <> latest is possible, but
> probably no good idea.
>
> In any case, if people don't like what they get, they can pip uninstall,
> and be back where they were before. I think this makes a huge difference.
>
> I think it makes sense to play even a bit more with the idea of
> "treating" stackless like an extension without actually being one.
> It might even be possible without virtualenv if we can manage to find
> a good bootstrap trick. virtualenv was the vehicle to think about it.
> Can be, can be not the best solution. Anyway better than all the humungous
> hackery that I thought  or two.
>
> At least for python 3.3, I think something is possible using the builtin
> venv features, installing stackless bootstrapping in a user environment.
>
> If you get a concrete idea, please tell me ASAP, because I want to draw
> a road-map where stackless will probably go in the near future.
> My EuroPython talk is early next week, I'm preparing till Saturday.

Will do.

Cheers,
Richard.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20120627/f84e1406/attachment.html>


More information about the Stackless mailing list