also install Python bindings for recent Ninja easyconfigs

[boegel]

(created using eb --new-pr)
requires:

• {lib}[GCCcore/10.2.0,GCCcore/10.3.0,GCCcore/11.2.0,GCCcore/11.3.0] scikit-build v0.15.0 w/ Python 3.8.6 + 3.9.5 + 3.9.6 + 3.10.4 #16024

[Micket]

I'm also really concerned we are building in some circular dependency hell here, the extra (build)dependencies really worries me for a build tool.

[boegel]

Ninja already depends on Python, and scikit-build sits directly on top of Python, so I don't see room for introducing a circular dependency?

[Micket]

As far as i could tell pypi "sources" aren't actually new code compared to the Ninja source tarball itself, just structured different + perhaps some autogenerated stuff (i think?), but, this approach worries me in 2 ways;

1. these version don't match with the easyconfig version, i think we should definitely do that
2. the python package also installs the bin/ninja binary (i think, at least, pip install ninja installs a bin/ninja). So i guess this is overwriting the one we just built?

so, perhaps we could opt to just use the pypi source? or, if possible, generate the python package from the original source?

[boegel]

There are no 1.10.1.x versions of scikit-build, so can't "match" with Ninja 1.10.1...

I should look into the bin/ninja part, that may be a problem I overlooked indeed.

The sources for the ninja Python package are in https://github.com/scikit-build/ninja-python-distributions .
That mentions that the wheels include an actual ninja binary, but I'm not sure that's also the case when building from source...

[boegel]

It looks like the bin/ninja that comes with the Python package is a light wrapper on top of the actual ninja binary (it's equivalent to the ninja function in https://github.com/scikit-build/ninja-python-distributions/blob/master/src/ninja/__init__.py)

[migueldiascosta]

The sources for the ninja Python package are in https://github.com/scikit-build/ninja-python-distributions .
That mentions that the wheels include an actual ninja binary, but I'm not sure that's also the case when building from source...

Seems it is? https://github.com/scikit-build/ninja-python-distributions/blob/450d8bb0dc375a536ee2a12eacca0d263dae3be2/CMakeLists.txt#L83-L102

[migueldiascosta]

It looks like the bin/ninja that comes with the Python package is a light wrapper on top of the actual ninja binary (it's equivalent to the ninja function in https://github.com/scikit-build/ninja-python-distributions/blob/master/src/ninja/__init__.py)

hm, it seems there are two ninjas (?) https://github.com/scikit-build/ninja-python-distributions/blob/450d8bb0dc375a536ee2a12eacca0d263dae3be2/CMakeLists.txt#L155-L156

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 4 out of 4 (4 easyconfigs in total)
node3131.skitty.os - Linux RHEL 8.4, x86_64, Intel(R) Xeon(R) Gold 6140 CPU @ 2.30GHz (skylake_avx512), Python 3.6.8
See https://gist.github.com/7349d8f1efab0d7831b17c7848876036 for a full test report.

[boegel]

Also installing the ninja Python package as an extension effectively wipes the original ninja binary:

$ module load Ninja/1.10.1-GCCcore-10.2.0
$ which ninja
/software/Ninja/1.10.1-GCCcore-10.2.0/bin/ninja

$ file $(which ninja)
/software/Ninja/1.10.1-GCCcore-10.2.0/bin/ninja: Python script, ASCII text executable

$ ninja --version
1.10.2.git.kitware.jobserver-1

ninja is clearly more than just Python bindings to the ninja binary, and as far I can tell there no way to point to an existing Ninja installation, so installing ninja as an extension along with the classic Ninja installation doesn't make much sense...