Add graalpy package to make Graalpy available as a Python implementation

[timfel]

Checklist

• Title of this PR is meaningful: e.g. "Adding my_nifty_package", not "updated meta.yaml".
• License file is packaged (see here for an example).
• Source is from official source.
• Package does not vendor other packages. (If a package uses the source of another package, they should be separate packages or the licenses of all packages need to be packaged).
• If static libraries are linked in, the license of the static library is packaged.
• Package does not ship static libraries. If static libraries are needed, follow CFEP-18.
• Build number is 0.
• A tarball (url) rather than a repo (e.g. git_url) is used in your recipe (see here for more details).
• GitHub users listed in the maintainer section have posted a comment confirming they are willing to be listed there.
• When in trouble, please check our knowledge base documentation before pinging a team.

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/graalpy, recipes/graalpy-meta) and found some lint.

Here's what I've got...

For recipes/graalpy:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [27, 28, 29, 30, 31, 32, 33, 34, 35, 36]

For recipes/graalpy:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

For recipes/graalpy-meta:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [16]

For recipes/graalpy-meta:

• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/graalpy, recipes/graalpy-meta) and found some lint.

Here's what I've got...

For recipes/graalpy:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [27, 28, 29, 30, 31, 32, 33, 34, 35, 36]

For recipes/graalpy-meta:

• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [16]

[msimacek]

Hi, I confirm I want to be listed as a maintainer of graalpy packages.

[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 (recipes/graalpy, recipes/graalpy-meta) and found it was in an excellent condition.

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/graalpy-meta, recipes/graalpy_standalone, recipes/python_abi) and found some lint.

Here's what I've got...

For recipes/python_abi:

• Feedstock with the same name exists in conda-forge.

[timfel]

It looks like the docker build runs out of memory building graalpy. Anything we can do there?

@isuruf I included the changes to python_abi in this PR, because the changes to the abi must be available to the graalpy-meta package during the build.

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/graalpy, recipes/python_abi) and found some lint.

Here's what I've got...

For recipes/graalpy:

• The recipe must have a build/number section.

For recipes/python_abi:

• Feedstock with the same name exists in conda-forge.

[timfel]

I don't understand why I get these builds in the log

    graalpy-22.3.0-python_3.9.* *_cpython-on-linux-64
    graalpy-22.3.0-python_3.10.* *_cpython-on-linux-64
    graalpy-22.3.0-python_3.8.* *_cpython-on-linux-64

There shouldn't be any variants, why am I not simply getting a single build?

[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 (recipes/graalpy) and found it was in an excellent condition.

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/graalpy, recipes/python_abi) and found some lint.

Here's what I've got...

For recipes/graalpy:

• The top level meta keys are in an unexpected order. Expecting ['package', 'source', 'build', 'outputs', 'about', 'extra'].

For recipes/python_abi:

• Feedstock with the same name exists in conda-forge.

[conda-forge-linter]

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

I wanted to let you know that I linted all conda-recipes in your PR (recipes/graalpy, recipes/python_abi) and found some lint.

Here's what I've got...

For recipes/python_abi:

• Feedstock with the same name exists in conda-forge.

[timfel]

@conda-forge-admin, please ping conda-forge/help-python

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-webservice.

I was asked to ping @conda-forge/help-python and so here I am doing that.

[timfel]

Some explanation:

There are two distributions for GraalPy: a) in a GraalVM, which means it runs the Java code on top of the Graal compiler and b) as a standalone native executable generated with GraalVM native image. The latter is created via a static analysis of the entire codebase, which takes about 11GB of RAM, too much for the Azure runners here. So I disabled the standalone distribution for now and only build the GraalVM-based distribution. The standalone should be preferred, which I've tried to express via the track_features: - openjdk for the GraalVM distribution build.

The python_abi maintained by @isuruf needs to be updated to be able to select GraalPy as a python implementation for other Python packages. Because there's a bit of a circular dependency here, with GraalPy providing the packages graalpy and python and the latter needing the python_abi build with GraalPy ABI, I've included the changes to python_abi in this PR so the CI run will work. What is the best approach to deal with this? My idea was:

1. Comment out the python package provided here and the references to python_abi
2. Remove the python_abi recipe from this PR
3. Merge this to make a graalpy-feedstock that for now only provides graalpy as a package
4. Propose my changes to python_abi-feedstock, because these can then reference the graalpy package newly available on conda-forge
5. Uncomment the python package provided in graalpy-feedstock, since now the python_abi build for GraalPy ABI should be available on conda-forge.

Are there better ways?

[timfel]

I think the test is missing a requires: pip, right? Or is that expected to just be there?

And just as I wrote this, I saw the new commit :) Sorry for the noise, I just thought maybe I was expected to already install pip in the graalpy prefix.

[timfel]

@isuruf thanks for the help with updating it. it played with the current recipe locally with various noarch packages, and it seems to work fine, that's great :)

[isuruf]

@conda-forge/openjdk, @conda-forge/python, we'll be adding variants of openjdk and python here. Are you okay with having these variants?

[timfel]

Hi, and happy new year :) Was there anything from the Python or Openjdk teams? (I don't see @isuruf's comment linking those, so not sure if the notification worked for those teams)