Update Spack recipe (v2.3.0.1, release documentation, sync packages)

[ajaust]

This PR does the following:

• Add v2.3.0.1 to the Spack recipe. The pull request in the Spack repository is here [py-pyprecice] add v2.3.0.1 and fix hash of v2.2.1.1 spack/spack#26846
• I synced the packages contained in this repository and the Spack repository.
• I added extra documentation

Restriction

• Do not merge before [py-pyprecice] add v2.3.0.1 and fix hash of v2.2.1.1 spack/spack#26846 is merged.
• Do not merge before Update Spack recipe (bugfix) #122 is figured out.

[ajaust]

I changed the GitHub workflow to print the version of the bindings build. It currently prints 0+unknown. Does this make sense?

[BenjaminRodenberg]

The Installed version of bindings is 0+unknown in the test (see https://github.com/precice/python-bindings/runs/3952442029#step:5:122) looks really strange. I will try to debug this. Generally it is useful to get something like Installed version of bindings is v2.3.0.1+5.gd65d39b here, because this allows us to quickly check that the CI is actually testing the right version. Currently we do not really know.

[BenjaminRodenberg]

As already discussed personally: Interesting that this has ever worked...

[ajaust]

In a local Spack environment (build as in the action) I get v2.3.0.1+7.g5cab31c as version. Maybe the GitHub action clones the repository in a different way?

[BenjaminRodenberg]

In a local Spack environment (build as in the action) I get v2.3.0.1+7.g5cab31c as version. Maybe the GitHub action clones the repository in a different way?

Same observation on my side, when I use docker run -ti precice/ci-spack-pyprecice-deps-1804. I'm a bit clueless right now how we could actually understand how the github action differs from a local build. Setting up a dummy repository with versioneer, github actions and spack is a possibility. But this sounds complicated.

[ajaust]

Maybe we should just add some git log -2 or a similar command to the action and see what it outputs? That should tell us whether we still have an intact git repository with the history.

[BenjaminRodenberg]

I just ran the CI locally using act -j build_spack. Here, everything looks as expected:

...
| ==> py-pyprecice: Successfully installed py-pyprecice-develop-zgzaqxe3rimtfztg6tnkshtaytsu6muu
|   Fetch: 0.00s.  Build: 5.27s.  Total: 5.27s.
| [+] /opt/spack/opt/spack/linux-ubuntu18.04-x86_64/gcc-7.5.0/py-pyprecice-develop-zgzaqxe3rimtfztg6tnkshtaytsu6muu
| Installed version of bindings is v2.3.0.1+9.g57c4791
[Build Spack/build_spack]   ✅  Success - Try to build py-pyprecice with spack and test it

This is also consistent with a local build on my system:

benjamin@...:~/Programming/python-bindings$ pip3 install --user .
Processing /home/benjamin/Programming/python-bindings
  Installing build dependencies ... done
  Getting requirements to build wheel ... done
    Preparing wheel metadata ... done
Requirement already satisfied: mpi4py in /usr/lib/python3/dist-packages (from pyprecice==2.3.0.1+9.g57c4791) (3.0.3)
Requirement already satisfied: numpy in /usr/lib/python3/dist-packages (from pyprecice==2.3.0.1+9.g57c4791) (1.17.4)
Building wheels for collected packages: pyprecice
  Building wheel for pyprecice (PEP 517) ... done
  Created wheel for pyprecice: filename=pyprecice-2.3.0.1+9.g57c4791-py2.py3-none-any.whl size=548674 sha256=e1a39961f81ca527ed5dbaba7ca50cbba8a6f40f55f2ebd122fc0c86ef3304ab
  Stored in directory: /home/benjamin/.cache/pip/wheels/4d/3d/7a/ce9222fbfcebb5d5c77b3da6b5f2ebe5d7a134bb0c296b25e3
Successfully built pyprecice
Installing collected packages: pyprecice
  Attempting uninstall: pyprecice
    Found existing installation: pyprecice 2.3.0.1+5.gd65d39b
    Uninstalling pyprecice-2.3.0.1+5.gd65d39b:
      Successfully uninstalled pyprecice-2.3.0.1+5.gd65d39b
Successfully installed pyprecice-2.3.0.1+9.g57c4791
benjamin@...:~/Programming/python-bindings$ python3 -c "import precice; print(precice.__version__)"
v2.3.0.1+9.g57c4791

To summarize: I'm really puzzled about the output of the action, if it is run online.

I would propose to merge this PR and create an issue on the output of the test. As long as we are not actively checking the output for correctness I would consider this a minor issue. I think we should treat this test with some care. However, it still answers the following questions from my perspective "Does the package.py work? Does our build system conflict?" (assuming that the correct revision is tested). Using act, we can still run the pipeline locally to make sure that actually the right commit is tested.