Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify supported Python runtime language version #4610

Open
gricey432 opened this issue May 6, 2024 · 4 comments
Open

Clarify supported Python runtime language version #4610

gricey432 opened this issue May 6, 2024 · 4 comments

Comments

@gricey432
Copy link

gricey432 commented May 6, 2024

Just after some clarification on what the supported Python versions are.

The docs specify Python 3.6 or higher, however the readme says Python 3.4 or higher

Python 3.4 went end of life in early 2019, 3.5 in late 2020, and 3.6 in late 2021

I'm happy to submit a PR either removing the 3.4 & 3.5 support code or updating the docs to say 3.4, just need some guidance on the project's status / goals here.

@kaby76
Copy link
Contributor

kaby76 commented May 11, 2024

It is unclear what it could be because the tester uses the latest available.

python-version: '3.x'
The plugin itself recommends setting an explicit version: (we recommend always setting Python version explicitly using the python-version or python-version-file inputs). In addition, to properly qualify a version range, you need to test each and every version in a range of versions in a test matrix in Github Actions workflow. In grammars-g4, I set the version explicitly to 3.10 because I had problems with version 3.8. https://github.com/antlr/grammars-v4/blob/153d66809d26425e5ac49cec77294f034d99eb0b/.github/workflows/main.yml#L113 However, that may be because some of the grammars have base class support code that relies on 3.10, and not with the generated parsers themselves. I don't test a range because it takes a long time to do this testing with each PR. And it can be expensive.

@gricey432
Copy link
Author

gricey432 commented May 13, 2024

Thanks for the response @kaby76, it's raised some further questions.

The plugin itself recommends setting an explicit version: (we recommend always setting Python version explicitly using the python-version or python-version-file inputs).

Where'd you find that line? The readme for the Python target doesn't seem to have that text in it and I'm unsure what a 'plugin' is in the ANTLR ecosystem. Also don't get any code matches on a Github search.

In addition, to properly qualify a version range, you need to test each and every version in a range of versions in a test matrix in Github Actions workflow. ... I don't test a range because it takes a long time to do this testing with each PR. And it can be expensive.

Hmm yeah having a look at the GitHub actions it looks like this repo is using one giant sequential job for the bulk of the Workflow. I feel like there'd be huge benefit in making a larger number of small jobs, but that's probably a different ticket.

The kind of code I'm proposing removal of (if 3.6 is minimum supported) is blocks like

if sys.version_info[1] > 5:

@kaby76
Copy link
Contributor

kaby76 commented May 13, 2024

Where'd you find that line?

Sorry, it is from https://github.com/actions/setup-python , the first big paragraph under "Basic usage".

Yes, validating the supported versions of a runtime environment is another problem. The change in the Antlr source code is also something that needs to be fixed with the correct value or removed.

@gricey432
Copy link
Author

Sorry, it is from https://github.com/actions/setup-python , the first big paragraph under "Basic usage".

Ah I misunderstood; thought you were talking about ANTLR suggesting pinning Python.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants