[enhc] support for multiple Python versions

[Myrausman]

Refactored GitHub Actions workflow to support multiple Python versions

[IIITM-Jay]

@aswaterman and @Myrausman, I would also like to mention one point here regarding the older python versions. The concerns comes from the commit python 3..6 compatibility. We should also give a look as what impact the existing codes have on older versions as well and by adopting the newer ones.

[Myrausman]

Thank you for your feedback, @IIITM-Jay. I'll certainly delve deeper into the potential implications of our existing code on older Python versions. I'm encountering a minor challenge with my GitHub Action workflow. While attempting to utilize Python 3.6, I'm receiving the error Version 3.6 was not found in the local cache.

Could you please provide some guidance on how to resolve this issue?

[IIITM-Jay]

Oh! I see, Sorry for the delayed response!

@aswaterman and @Myrausman , The error that you are facing with this PR currently is that Python 3.6 is no longer available in the GitHub Actions environment. Python 3.6 reached its end-of-life (EOL) on December 23, 2021 and is no longer supported or maintained. The link will also guide the EOL of other versions in concern.

But, if we really want to test against Python 3.6, we have few options for the same:

1. We can use Docker Container that has Python 3.6 installed. It will act as an Isolated environment without needing a self-hosted runner. Will come to this self-hosted runner, in next point. But it may come up with code complexities.
2. We can have our own Self-Hosted Runner by setting up a self-hosted GitHub Actions with Python 3.6 installed. This allows to maintain control over the Python versions available. But again, requires maintenance and management of the runner.
3. Legacy actions/setup-python Versions: I am not sure with this, but I think, older versions of actions/setup-python might still support Python 3.6. Again, I can't suggest this one here due to potential security vulnerabilities and lack of support. For the sake of simplicity to make my point clear, I am thinking of this :

- name: Set up Python 3.6
  uses: actions/setup-python@v1
  with:
    python-version: '3.6'

[IIITM-Jay]

@aswaterman , few more suggestions:

1. We can use updated GitHub Actions syntax to use the latest versions of GitHub Actions for better features and security.I meant about actions/checkout and actions/setup-python.
2. We can specify python dependencies efficiently by combining the pip install commands to reduce the number of steps and improve caching.
3. We can speed up the workflows by utilizing cache.

Thinking to do above related things in a separate PR elaborating each steps and the reasons why we are adopting those

[sequencer]

I wonder should the python parser separates from this repo as a standalone project? Originally, it was simple. But recently the trend of it seems to grow into some big project that even needs multiple python versions support. It’s kinda unbelievable for such a simple project.

IMHO, the change to parser logic is always unrelated to the opcodes itself, and seldom does the opcode changes(only add new instructions and move ops from unratified).

I think we maybe can formally define the syntax of opcodes and move the parser logic to another repo if the python parser is too mutable.

[aswaterman]

I'm OK with ditching support for Python 3.6, so we can revise this PR to only test against 3.8 and above if that's what we decide is best.

And I support any sensible improvements to improve the extent of our CI or speed it up.

[IIITM-Jay]

@Myrausman as per @rpsene, we would be doing these for python versions 3.9 to 3.13 as they all are supportive according to the Current Status of Python versions as 3.8 has also reached its EOL