Add packaging of MeshPy to testing

[isteinbrecher]

After discussing last week with @clemens-fricke how this is done in splinepy, I propose to replace the current "non-editable" install test by tests where we first build the MeshPy wheel and then install the wheel. By doing so, we should be able to somewhat guarantee that changes to the code don't affect the packaging behaviour. @clemens-fricke do you agree?

[davidrudlstorfer]

@isteinbrecher thanks a lot for tackling this in the first place!

It's really nice that the wheel builds and works as intended. I am not 100% happy with the workflow though. I think we should not bring the wheel building process into our testing procedure.

Not too long ago I invested some time into the wheel building process of rapidyaml (https://github.com/biojppm/rapidyaml).

If we want to publish the wheels to pypi (hopefully in the near future) we need to build the wheels for a lot of systems (i.e., ubuntu, windows, macos and for all python versions => at least 15 different wheels)

In my opinion we should simply make a new workflow "build (and publish) wheels" and build all the wheels via a matrix there. For now we could upload the resulting wheels as an artifact.

In testing we should then download the wheel from the other completed job and install it. Additionally, I think it would be nice to keep the non editable install testing (to be on the safe side) and add the installation via a wheel.

It should be pretty straight forward to update the current process to my proposed one. Let me know what you think:)

[isteinbrecher]

Thanks for your thoughts @davidrudlstorfer , my initial thoughts behind this PR were the following: Building of the wheel did not work, since the Cython source files were not copied, so we needed the MANIFEST.in file. I would like to test that building of the wheel works, so we are even closer to a smooth transition when we publish the repo.

As you said, once we go to pypi, we have to build for many different versions and OS systems. The question is, if we want to do that for every pipeline run or just for special cases, e.g., merging to main. I chose the current approach so we don't build 10+ wheels each time we test. But seeing that the wheel building is not that computationally expensive, I would be also OK with that solution and then just downloading the wheel later on.

I think that there is not much difference between an installation from a wheel and the editable installation - so I thought testing just one is fine. But after second thought, you are right, let's keep both, one never knows.

We can try to figure out a way how we want to test the installation / building in the near future (publishing to pypi will be another topic) and then apply this within this PR. @davidrudlstorfer I have no strong feelings here and sine you are the MeshPy testing expert I am very curious on your opinion.

Would something like this make sense:
0. Code checks

1. Build wheels for all suported combinations
2. Testsuite (editable, non-editable and from wheel) -> The question here is, which python versions test which installation mode with which test configuration...

[davidrudlstorfer]

@isteinbrecher I think this sounds like a solid plan. As you've mentioned the pipelines of MeshPy are that fast (and they are running in parallel) that we can add more. In the last few months we've seen that everything works perfectly and we do not have any problems with all of the versions.

Therefore, I think we can simply also just build all wheels in the PR pipelines (to ensure that it works) and only push them in main.

Regarding the setup for the pipelines I think that we can also do everything in parallel. The code checks and the testing occures in parallel right now. Also the wheels could be built in parallel to testing. Only the testing in combination with wheels depend on the prior built wheels. These could automatically start once the wheel is available.