Upgrade python to 3.10.0

[nvuillam]

Upgrade python to 3.10.0

[nvuillam]

Mega-Linter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ BASH	bash-exec	6		0	1.41s
✅ BASH	shellcheck	6		0	1.64s
✅ BASH	shfmt	6	0	0	1.4s
✅ COPYPASTE	jscpd	yes		no	2.77s
✅ CREDENTIALS	secretlint	yes		no	3.4s
✅ CSS	stylelint	1	0	0	1.47s
✅ DOCKERFILE	dockerfilelint	1		0	0.52s
✅ DOCKERFILE	hadolint	1		0	1.12s
✅ GIT	git_diff	yes		no	0.23s
✅ JSON	eslint-plugin-jsonc	20	0	0	2.9s
✅ JSON	jsonlint	19		0	11.79s
✅ JSON	v8r	20		0	19.41s
✅ MARKDOWN	markdownlint	195	0	0	5.67s
✅ MARKDOWN	markdown-link-check	195		0	139.02s
✅ MARKDOWN	markdown-table-formatter	195	0	0	5.23s
✅ OPENAPI	spectral	1		0	1.8s
⚠️ PYTHON	bandit	140		64	2.71s
✅ PYTHON	black	140	0	0	3.48s
✅ PYTHON	flake8	140		0	2.77s
✅ PYTHON	isort	140	0	0	0.62s
✅ PYTHON	mypy	140		0	79.64s
✅ PYTHON	pylint	140		0	19.62s
✅ SPELL	cspell	465		0	44.58s
✅ SPELL	misspell	312	0	0	0.53s
✅ XML	xmllint	2		0	0.24s
✅ YAML	prettier	77	0	0	4.41s
✅ YAML	v8r	20		0	32.36s
✅ YAML	yamllint	78		0	1.7s

See errors details in artifact Mega-Linter reports on GitHub Action page

[Kurt-von-Laven]

Black recently (literally 14 hours ago) added support for Python 3.10 at version 21.11b1, and it looks like your automation already picked up that change, so I believe this PR is unblocked unless there is another linter that can't yet handle Python 3.10 that I'm unaware of.

[nvuillam]

@Kurt-von-Laven good catch, let's see what CI says :)

[nvuillam]

MegaLinter status: ⚠️ WARNING

Descriptor	Linter	Files	Fixed	Errors	Elapsed time
✅ BASH	bash-exec	6		0	0.02s
✅ BASH	shellcheck	6		0	0.26s
✅ BASH	shfmt	6	0	0	1.42s
✅ COPYPASTE	jscpd	yes		no	1.91s
✅ CREDENTIALS	secretlint	yes		no	3.16s
✅ DOCKERFILE	dockerfilelint	1		0	0.22s
✅ DOCKERFILE	hadolint	1		0	0.69s
✅ GIT	git_diff	yes		no	0.23s
✅ JSON	eslint-plugin-jsonc	21	0	0	2.21s
✅ JSON	jsonlint	19		0	4.29s
✅ JSON	v8r	21		0	13.36s
✅ MARKDOWN	markdownlint	197	0	0	4.81s
✅ MARKDOWN	markdown-link-check	197		0	42.82s
✅ MARKDOWN	markdown-table-formatter	197	0	0	4.53s
✅ OPENAPI	spectral	1		0	1.05s
⚠️ PYTHON	bandit	143		64	2.2s
✅ PYTHON	black	143	0	0	2.89s
✅ PYTHON	flake8	143		0	1.99s
✅ PYTHON	isort	143	0	0	0.53s
✅ PYTHON	mypy	143		0	61.53s
✅ PYTHON	pylint	143		0	17.53s
✅ SPELL	cspell	469		0	26.5s
✅ SPELL	misspell	314	0	0	0.46s
✅ XML	xmllint	2		0	0.01s
✅ YAML	prettier	77	0	0	3.42s
✅ YAML	v8r	20		0	21.32s
✅ YAML	yamllint	78		0	1.38s

See errors details in artifact MegaLinter reports on GitHub Action page

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this pull request should stay open, please remove the O: stale 🤖 label or comment on the pull request.

[Kurt-von-Laven]

I am curious whether upgrading rstfmt and rstcheck would address the build errors at this point, so I clicked "Update branch."

[Kurt-von-Laven]

Well, that changed the error message:

Error: Command failed: mega-linter-runner --path ./.. --release test-Kurt-von-Laven-updatePython -e "ENABLE=YAML" --nodockerpull
Unable to find image '***/***:test-Kurt-von-Laven-updatePython' locally
docker: Error response from daemon: manifest for ***/***:test-Kurt-von-Laven-updatePython not found: manifest unknown: manifest unknown.
See 'docker run --help'.

Is this possibly a build pipeline issue?

[nvuillam]

The issue is probably from the docker build step before :)

[nvuillam]

@Kurt-von-Laven FYI -> sgerrand/alpine-pkg-glibc#169 :(

[Kurt-von-Laven]

Oof; I see. I wish it were released via some stable package manager, but personally I don’t know that I want MegaLinter to be in the business of packaging its dependencies at this stage of the project since there are so many wonderful linters that we could add instead for less effort. Maybe we can cache the package since GitHub Actions recently expanded its cache limit to 10 GB? Or maybe add retry logic and/or incremental downloading in case the connection fails? What would happen if we eliminated the dependency altogether?

[nvuillam]

I think it's used only for dart linter...
Do you know a way to cache a package ? Or even to not verify it with GPG key ? If yes it could be great ^^

[nvuillam]

By the way, with python 3.10, only test failures are rstfcheck and rstfmt.
Do people still use rst format ? :D
Maybe we could get rid of those linters in v6 , as they seem not maintained anymore anyway :)

FAILED /tests/test_/linters/rst_rstcheck_test.py::rst_rstcheck_test::test_get_linter_help
FAILED /tests/test_/linters/rst_rstcheck_test.py::rst_rstcheck_test::test_get_linter_version
FAILED /tests/test_/linters/rst_rstcheck_test.py::rst_rstcheck_test::test_success
FAILED /tests/test_/linters/rst_rstfmt_test.py::rst_rstfmt_test::test_get_linter_help
FAILED /tests/test_/linters/rst_rstfmt_test.py::rst_rstfmt_test::test_get_linter_version
FAILED /tests/test_/linters/rst_rstfmt_test.py::rst_rstfmt_test::test_success

[Kurt-von-Laven]

I might be missing something, but I believe we can simply use GitHub's cache action. Is apk add --no-cache glibc-${GLIBC_VERSION}.apk the step that is verifying the GPG key? I'm struggling to find comprehensive documentation on that command, but I wonder what --allow-untrusted does after seeing https://wiki.alpinelinux.org/wiki/Package_management#Add_a_Package?

TL;DR I wholeheartedly agree about removing rstcheck and rstfmt for v6.

StackOverflow has 1,155 questions tagged reStructuredText, so it sounds like it's a documentation format that is essentially only used by a small handful of Python developers. There were only 8 hits for rstcheck, so it looks like most folks using reStructuredText don't use rstcheck, and like you say the project is no longer seeing releases. rstfmt had a release 3 months ago, but their README opens with: "Highly experimental and unstable. Do not depend on this yet." My intuition overall is that MegaLinter users as a whole will probably prefer having a lot of tools that play nice together out of the box to having even more tools but also more headaches. On top of that, we could easily end up getting completely bogged down by maintenance if we aren't careful. I'm sure we will hear from our users if reStructuredText is very important to them.

[nvuillam]

Agreed, let's kill them in next version :D

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity.
It will be closed in 14 days if no further activity occurs.
Thank you for your contributions.

If you think this pull request should stay open, please remove the O: stale 🤖 label or comment on the pull request.