You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[GraalPy](https://github.com/oracle/graalpython) is compatible with many Python
4
-
libraries, including those that extend the Python runtime with native code.
5
-
However, implemented in Java and thus binary incompatible with existing
6
-
extensions, users of native Python extension libraries such as NumPy, SciPy, or
7
-
PyTorch have to build their own binaries when installing these libraries. For
8
-
many libraries, this means installing additional build dependencies and sitting
9
-
through long and resource-intensive compilation processes.
10
-
11
-
This project is meant to be a place for the community to collect build recipes
12
-
for as many popular packages as possible that can then be built once with
13
-
GitHub Actions for each major release of GraalPy.
3
+
[GraalPy](https://github.com/oracle/graalpython) is compatible with many Python libraries, including those that extend the Python runtime with native code.
4
+
However, implemented in Java and thus binary incompatible with existing extensions, users of native Python extension libraries such as NumPy, SciPy, or PyTorch have to build their own binaries when installing these libraries.
5
+
For many libraries, this means installing additional build dependencies and sitting through long and resource-intensive compilation processes.
6
+
7
+
This project is meant to be a place for the community to collect build recipes for as many popular packages as possible that can then be built once with GitHub Actions for each major release of GraalPy.
8
+
9
+
## Quickstart
10
+
11
+
1.[Fork](../../../../fork) this repository.
12
+
2. Go to the [actions](../../../../actions) on your fork.
13
+
3. On the left, choose the Workflow for the OS you are interested in.
14
+
15
+

16
+
17
+
4. Click on "Run workflow".
18
+
You can enter a package name or build all packages.
19
+
See [the spec list](../../../../blob/master/scripts/wheelbuilder/generate_workflow.py) for which packages are available.
20
+
21
+

14
22
15
23
## How to contribute
16
24
17
-
There should be only one relevant file, `generate_workflow.py`. In it we
18
-
collect `BuildSpec` objects that define how to build a particular package. Many
19
-
packages do not need special definitions, just a name and maybe which platforms
20
-
to build it for. System package dependencies can be specified by platform where
21
-
needed. Dependencies between specs are not strictly necessary, but can reduce
22
-
the overall build times and thus resource usage of GitHub Action runners.
25
+
There should be only one relevant file, `generate_workflow.py`.
26
+
In it we collect `BuildSpec` objects that define how to build a particular package.
27
+
Many packages do not need special definitions, just a name and maybe which platforms to build it for.
28
+
System package dependencies can be specified by platform where needed.
29
+
Dependencies between specs are not strictly necessary, but can reduce the overall build times and thus resource usage of GitHub Action runners.
23
30
24
-
Changes to `generate_workflow.py` are reflected in the build specs by running
25
-
the file. It creates GitHub Action workflow files, one for each platform, and a
26
-
giant one with all jobs.
31
+
Changes to `generate_workflow.py` are reflected in the build specs by running the file.
32
+
It creates GitHub Action workflow files, one for each platform, and a giant one with all jobs.
27
33
28
34
## How to run this
29
35
30
-
Many packages use a lot of resources to build, and even those that do not
31
-
quickly add up. We have chosen GitHub Action workflows as the cross-platform
32
-
specification for how to build packages.
36
+
Many packages use a lot of resources to build, and even those that do not quickly add up.
37
+
We have chosen GitHub Action workflows as the cross-platform specification for how to build packages.
33
38
34
39
### Running actions locally with nektos/act
35
40
36
-
[Act](https://github.com/nektos/act) allows running GitHub actions locally. We
37
-
can use that to just build packages on a local machine:
We can use that to just build packages on a local machine:
38
43
39
44
```
40
45
./act --artifact-server-path /tmp/artifacts \
@@ -45,11 +50,8 @@ can use that to just build packages on a local machine:
45
50
--input name=psutil
46
51
```
47
52
48
-
You can vary the `--input name=` argument to select which package to build or to
49
-
build all.
53
+
You can vary the `--input name=` argument to select which package to build or to build all.
50
54
51
-
On Linux you will need Docker or Podman. If you're using Podman, make sure you
52
-
are running the system service (e.g. `podman system service -t 0` to run it in
53
-
a shell), have symlinked or aliased `docker` to `podman`, and prepared you env
54
-
with `export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock` to allow
55
-
`act` to pick up where podman is listening.
55
+
On Linux you will need Docker or Podman.
56
+
If you're using Podman, make sure you are running the system service (e.g.
57
+
`podman system service -t 0` to run it in a shell), have symlinked or aliased `docker` to `podman`, and prepared you env with `export DOCKER_HOST=unix://$XDG_RUNTIME_DIR/podman/podman.sock` to allow `act` to pick up where podman is listening.
0 commit comments