fixes for python cache

[vivus-ignis]

What this PR does:

This PR introduces separate composite github actions for a) normal library setup (to be used by the library's consumers, i.e. gardenlinux/gardenlinux workflows) and b) for a development setup (to be used for workflows in this very repository).

Normal library setup action now uses only pip and installs library package wheel which should be published beforehand on github release page. Before this change we have a more complicated setup which selected different package managers based on how the action was called and a special 3rd party github action to actually install (and optionally cache) the package. This, I may argue, is not needed, as it abstracts away what's going on and makes reasoning about the pipeline harder.

The new development setup uses poetry as it is the package management tool used, well, for the development of this project. Development setup, obviously, installs everything using the commit that triggered the pipeline.

Why we need this?:

• Because of the fact that the setup composite action relies on a package wheel and does it install "from source" as before, switching gardenlinux workflows to a new python library version requires an additional step -- the actual package release. This is a step towards the proper release process of the library.
• Dev setup now completely separated from user setup and, as expected, works with the source code commit that triggered the change
• We use less 3rd party GHA code that introduces unnecessary complexity and makes troubleshooting harder (such a 3rd party GHA already broke nightly because of... a symlink in a feature directory -- and this behavior is hard to predict!)

Which issue(s) this PR fixes:
Fixes #255

[NotTheEvilOne]

Support for both pip (current tests in GardenLinux repository) and poetry is required. Please verify if GitHub action input cache-dependency-path. of setup-python can fix this issue. If not we could also remove the GardenLinux Git submodule from this repository and check it out only if required. Not sure if this solution would help us with our GardenLinux repository.

If not please investigate first deeper what causes our pipelines to fail. No changes are implemented since the last tagged version of setup-python as far as I know. Once we understand better what causes this newly issue we could fix it proberly.

[vivus-ignis]

Support for both pip (current tests in GardenLinux repository) and poetry is required. Please verify if GitHub action input cache-dependency-path. of setup-python can fix this issue. If not we could also remove the GardenLinux Git submodule from this repository and check it out only if required. Not sure if this solution would help us with our GardenLinux repository.

If not please investigate first deeper what causes our pipelines to fail. No changes are implemented since the last tagged version of setup-python as far as I know. Once we understand better what causes this newly issue we could fix it proberly.

Agreed re: proper fix. This is a draft I'm using for now to test some assumptions.

[yeoldegrove]

@vivus-ignis Already talked to @NotTheEvilOne about this some time back... would it be possible... if we anyways touch this, to change our workflow files to not hard-code the actual versions of the library? I would imagine this would simplify a lot how to call the workflows from external (based on tag) and also internally (based on branch/commit).
Did not look into this more deeply, yet though.

[NotTheEvilOne]

This PR remove functionality needed and can not be merged in it's current form. It is superseeded with #257.

Reasoning:

• Intended purpose has been to fix an issue with dangling symlinks and setup-python running glob failing to follow these broken symlinks. The PR does not address this issue at all.
• The additional workflow seems to be counter-productive and does not add value to the execution of workflows in this repository.
• Building a wheel file might look like some kind of "distributable artifact" but does not add any value as well. Python packagers still read the requirements of the wheel file and try to satisfy dependencies on runtime. The wheel file in this context is like packing up the python-gardenlinux-lib repository at the specific Git hash.
• For pinning / reproducibility the Git hash used for e.g. GitHub releases as well points to a specific version useful for third-parties including the GardenLinux repository.
• The intended use of GitHub caching may result in unexpected behavior on the pytests matrix where multiple versions of Python are tested against the code.
• No solution has been found so far to remove the pinning of tags while calling child workflows in the same repository. Only solution would be some kind of "stable" or "latest" tag but this would counterfeit the use of tags for pinning to a specific version. @yeoldegrove

[vivus-ignis]

This PR remove functionality needed and can not be merged in it's current form. It is superseeded with #257.

Reasoning:

• Intended purpose has been to fix an issue with dangling symlinks and setup-python running glob failing to follow these broken symlinks. The PR does not address this issue at all.

This PR addresses the issue by not using caching from setup-python and instead relying on the cache action.

• The additional workflow seems to be counter-productive and does not add value to the execution of workflows in this repository.

What exactly is counter-productive?

• Building a wheel file might look like some kind of "distributable artifact" but does not add any value as well. Python packagers still read the requirements of the wheel file and try to satisfy dependencies on runtime. The wheel file in this context is like packing up the python-gardenlinux-lib repository at the specific Git hash.

Building the wheel file forces us to start having at least some release process.

• For pinning / reproducibility the Git hash used for e.g. GitHub releases as well points to a specific version useful for third-parties including the GardenLinux repository.
• The intended use of GitHub caching may result in unexpected behavior on the pytests matrix where multiple versions of Python are tested against the code.

Tests will not be affected because for dev pipelines no caching is used in the proposed PR.

• No solution has been found so far to remove the pinning of tags while calling child workflows in the same repository. Only solution would be some kind of "stable" or "latest" tag but this would counterfeit the use of tags for pinning to a specific version. @yeoldegrove

The best way to solve this issue is not to rely on tags and start doing proper releases with release artifacts that will be used downstream to install the library. Just like any project on pypi does (and for a reason!)

[vivus-ignis]

This PR remove functionality needed and can not be merged in it's current form. It is superseeded with #257.

By no means it "superseeds" this PR. It fixes a bug, while I propose to fix a bigger issue: a sloppy release process.