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

Python version checked too late #268

Open
LawrenceEsswood opened this issue Jan 25, 2022 · 12 comments
Open

Python version checked too late #268

LawrenceEsswood opened this issue Jan 25, 2022 · 12 comments
Labels

Comments

@LawrenceEsswood
Copy link
Contributor

Just tried to run cheribuild on an old machine. We check the python version in pycheribuild/utils.py, but this is included rather late in ./pycheribuild/main.py, which includes the config loader first which will give obscure asserts on old versions of python. A comment in main.py reveals that this include order is important? Shall I pull up the version check out of utils.py into main?

@jrtc27
Copy link
Member

jrtc27 commented Jan 25, 2022

If you hoist it above imports then you'll make flake8 unhappy and need a whole load of E402 waivers... not particularly appealing to me. To be honest the whole concept is a bit futile, unless you do it as literally the first thing in every top-level Python script you have no clue what could run before your version check and thus be using unsupported language features. I think it's fine to just blow up if you use an ancient Python version.

@LawrenceEsswood
Copy link
Contributor Author

I mean, 3.5 is hardly ancient. Is a guaranteed error message for unsupported python really something we don't care to have?

@LawrenceEsswood
Copy link
Contributor Author

Also: why must we live under the tyranny of format checkers! No machine can tell me what to do!

@jrtc27
Copy link
Member

jrtc27 commented Jan 25, 2022

Python 3.5 was released in 2015.

@LawrenceEsswood
Copy link
Contributor Author

And is the version you get on Ubuntu 16.04, which is EOL in 2026, and so still perfectly reasonable that people may be using it.

@LawrenceEsswood
Copy link
Contributor Author

We could always put the version check in the file that seems to assert when used with old versions of python. Seems sensible, as it does require it.

@jrtc27
Copy link
Member

jrtc27 commented Jan 25, 2022

You have to pay for it, or get it for free as an individual with up to 3 machines for personal use. It's out of standard support. Using it in 2022 is not reasonable, you won't be getting security updates unless you really try.

@jrtc27
Copy link
Member

jrtc27 commented Jan 25, 2022

(and the README clearly states that Ubuntu 18.04/20.04 are the supported versions)

@jrtc27
Copy link
Member

jrtc27 commented Jan 25, 2022

I don't want version checks everywhere that uses f-strings or other features not in Python 3.5. That leads to insanity.

@LawrenceEsswood
Copy link
Contributor Author

Which is why we should just put the check in the top-level file. And flake can go @*!& itself.

@jrtc27
Copy link
Member

jrtc27 commented Jan 25, 2022

You can do that but that's not __main__.py, that's the files that include pycheribuild, of which there are 7 (look for the sys.path.insert/append).

And such comments about flake8 are not constructive.

@LawrenceEsswood
Copy link
Contributor Author

Poor flake8 =(. Sorry, I will have a look at where you suggest.

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

No branches or pull requests

2 participants