Seeing "python.linting." are deprecated errors on latest universal linux image.

[vandiesel22]

Currently when we boot up codespaces we continue to see the following errors show up:

2023-11-07 14:46:46.308 [error] Following setting is deprecated: "python.linting.pylintEnabled"
2023-11-07 14:46:46.308 [error] All settings starting with "python.linting." are deprecated and can be removed from settings.
2023-11-07 14:46:46.308 [error] Linting features have been moved to separate linter extensions.
2023-11-07 14:46:46.308 [error] See here for more information: https://code.visualstudio.com/docs/python/linting
2023-11-07 14:46:46.308 [error] Please install "pylint" extension: https://marketplace.visualstudio.com/items?itemName=ms-python.pylint

As part of our investigation we did ensure that we removed any references of python.linting within our code base so we can confirm we do not have any of the deprecated linting settings enabled. Just to make sure however we did start up a codespaces in a repo that had no settings and only the base image configured, we continued to see the linting errors.

Within our devcontainer.json we are currently configured to use the image mcr.microsoft.com/devcontainers/universal:linux. We can confirm that we are pulling the following SHA, b2283ca173f95538dbb9db429d25f48b4e37552c51771ce3d467ac4851e891db, which seems to align with the current latest shown on https://mcr.microsoft.com/en-us/product/devcontainers/universal/tags.

Upon some inspection within codespaces we found that the following settings are within /home/codespace/.vscode-remote/data/Machine/settings.json.

"python.formatting.autopep8Path": "/usr/local/py-utils/bin/autopep8",
"python.formatting.blackPath": "/usr/local/py-utils/bin/black",
"python.formatting.yapfPath": "/usr/local/py-utils/bin/yapf",
"python.linting.banditPath": "/usr/local/py-utils/bin/bandit",
"python.linting.enabled": true,
"python.linting.flake8Path": "/usr/local/py-utils/bin/flake8",
"python.linting.mypyPath": "/usr/local/py-utils/bin/mypy",
"python.linting.pycodestylePath": "/usr/local/py-utils/bin/pycodestyle",
"python.linting.pydocstylePath": "/usr/local/py-utils/bin/pydocstyle",
"python.linting.pylintEnabled": true,
"python.linting.pylintPath": "/usr/local/py-utils/bin/pylint",

As far as we can tell it seems these settings should have been removed with the following PR, https://github.com/devcontainers/images/pull/671/files. So it leads us to believe that although we are pulling the latest image, the latest image may not contain all of the latest changes?

Curious if anyone may have thoughts.
Thanks

[bamurtaugh]

Thank you for filing! I'd love to get @samruddhikhandale's thoughts.

[samruddhikhandale]

Thanks for looping me in.

The deprecated settings were removed and released in the #826 release. Hence, b2283ca173f95538dbb9db429d25f48b4e37552c51771ce3d467ac4851e891db should ideally have the updates.

However, if you were using codespaces cached image, then there is some delay and you shouldn't have got b2283ca173f95538dbb9db429d25f48b4e37552c51771ce3d467ac4851e891db image in that case.

@vandiesel22 are you still seeing this issue?

[vandiesel22]

Hi @samruddhikhandale,

Thanks for the response. As of this morning We are using mcr.microsoft.com/devcontainers/universal:linux@sha256:032969569844454a0593b24800fc2c0fb7b83717d6b7aa0df82909003e90ab35 image.

From https://mcr.microsoft.com/en-us/product/devcontainers/universal/tags it seems we are using the latest image but we continue to see the pylint errors listed above. Also I should note we do not pin the images so we are always pulling the latest image from Microsoft. I am unsure if the change has been populated to all images?

Thanks,
Van

[samruddhikhandale]

Hi,

Thanks for reporting and apologies for missing this out.

@vandiesel22 I believe you are using Codespaces? Was able to reproduce as well, I have a Codespace PR open to clean this up.

[samruddhikhandale]

I believe you are using Codespaces? Was able to reproduce as well, I have a Codespace PR open to clean this up.

Closing as this is fixed, feel free to reopen if it pops back up. Thanks!

[vandiesel22]

@samruddhikhandale yes we are using codespaces. And I can confirm we are no longer seeing the warn. Thank you!