Stackless Python 2.7.13 [create new branch "2.7-stackless"]

[akruis]

Hello,

I'm one of the maintainers of Stackless Python (www.stackless.com). This pull request aims for providing Stackless Python as an optional alternative implementation of python besides regular C-Python. This pull request must be merged into a new branch, because it is not intended to replace or modify the existing python packages in any way. I propose the name "2.7-stackless" for the new branch.

Stackless Python is a fork of C-Python with a long tradition. It provides co-routines and extended serialisation (pickling) capabilities over C-Python. Nowadays Stackless Python is fully API and ABI compatible to C-Python. Because Stackless Python is a complete Python implementation by itself, it conflicts with regular C-Python. A conda environment can use either Stackless-Python or C-Python but not both. Therefore it is not possible to provide Stackless Python as a separate feedstock besides python. Instead a conda "feature" is used: the new meta-package "stackless" (conda-forge/staged-recipes#2714) tracks the feature "stackless". And this pull request provides a recipe to package Stackless Python as "python" with the feature "stackless". Now, if the meta package "stackless" is installed, conda will prefer the python package with the feature "stackless" over the regular one.

The "test" section of this recipe depends on the new meta package "stackless". Therefore the test will fail until pull request conda-forge/staged-recipes#2714 has been merged and the meta package "stackless" is available. (Without this dependency conda would install regular python into the test environment.)

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[akruis]

Currently all builds fail. Linux and OS-X build, but tests fail, because the meta package "stackless" is not yet available.

But Windows fails to untar the source. Stackless comes as a tar.xz archive. I already added package "xz" as a build requirement, because it provides the command "unxz" (at least on linux). I'm going to reproduce this on my Windows box tomorrow.

This is the relevant part of the AppVeyor log:

The following NEW packages will be INSTALLED:
    vs2015_runtime: 14.0.25420-0 conda-forge
    xz:             5.2.2-0      conda-forge
Source cache directory is: C:\bld\src_cache
Downloading source to cache: stackless-2713-export.tar.xz
Downloading http://www.stackless.com/binaries/stackless-2713-export.tar.xz
Success
unxz is required to unarchive .xz source files.

Update: it's a well known issue: conda/conda-build#1536

[jakirkham]

Having Stackless Python in conda-forge does sound really cool. I'd like to reach out to folks at Continuum to see if they have any thoughts on how we approach this.

cc @msarahan @mingwandroid @ccordoba12 @mcg1969

[akruis]

@jakirkham I'm glad you like the idea of getting Stackless into conda-forge.

Meanwhile I created a tar.bz2 source archive on stackless.com and modified the recipe to use it. Now all three build bots build the package and fail when they try to install the stackless meta package (conda-forge/staged-recipes#2714).

[jakirkham]

So, as I don't know as much about the inner workings of Stackless, would we need to rebuild C extension packages to work with Stackless?

[jjhelmus]

I'm wondering if a different package name shouldn't be used for stackless Python rather than a feature? I do not believe conda provides a mechanism for selecting features without installing a meta-package. Users might be suprised if conda install -c conda-forge python did not install CPython. For better-or-worse most Python users equate Python == CPython.

[akruis]

@jakirkham No, Stackless is API and ABI compatible to C-Python. There is no need rebuild existing extension packets. With other words: Stackless Python is C-Python with some additions. In theory, you could replace C-Python entirely with Stackless Python.

[akruis]

@jjhelmus Stackless-Python is a C-Python with some additions. This makes it hard, to install C-Python and Stackless in the same conda environment. There are file name collisions: python27.dll for instance. The Stackless installation would also need its own Lib and include directory. All this can be resolved, but it gets nasty.

Now, if we create a Stackless package, that installs Stackless besides C-Python, how to select the right binary for an application? If the application uses Stackless features, you must use the “python”-binary provided by the Stackless package. But the user of an application might not know, that the application contains a module, that requires Stackless Python.

Therefore I would like to use the conda feature mechanism. The recommended way to track a feature is to use a meta package. Unless the meta package gets installed, you never get Stackless Python and most users of conda-forge won't ever notice, that Stackless Python is available. Of course the meta package must not be installed by default. But I don't think, that it is common to install all conda-forge packages.

[mattip]

I think this can be closed.