`redhat.ansible` extension must not modify the workspace settings (with `ansible.python.interpreterPath`).

[DeadNews]

Summary

redhat.ansible extension must not modify the workspace settings (with ansible.python.interpreterPath).

Example: https://github.com/DeadNews/deadnews-template-ansible/pull/28/commits/8b537fbb3cb20b2e58f7061fa59026f371c83a6a

${workspaceFolder}/.vscode/settings.json сan be used on different devices by different people. This config is not suitable for mandatory storage of ansible.python.interpreterPath setting. Moreover, redhat.ansible changes the workspace settings whenever the python interpreter changes. Even if this is in a regular python repository and has nothing to do with ansible.

ms-python.python does not need to modify the workspace settings (${workspaceFolder}/.vscode/settings.json) to select and remember an interpreter for the current workspace.

Refs: https://github.com/ansible/vscode-ansible/issues/775, https://github.com/ansible/vscode-ansible/discussions/898

Extension version

v2.1

VS Code version

1.77

Ansible Version

ansible [core 2.15.0]
  config file = /home/user/git/deadnews-template-ansible/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/user/.cache/pypoetry/virtualenvs/deadnews-template-ansible-EQAYLr04-py3.10/lib/python3.10/site-packages/ansible
  ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/user/.cache/pypoetry/virtualenvs/deadnews-template-ansible-EQAYLr04-py3.10/bin/ansible
  python version = 3.10.10 (main, Mar  5 2023, 22:26:53) [GCC 12.2.1 20230201] (/home/user/.cache/pypoetry/virtualenvs/deadnews-template-ansible-EQAYLr04-py3.10/bin/python)
  jinja version = 3.1.2
  libyaml = True

OS / Environment

Linux

Relevant log output

No response

[cidrblock]

@DeadNews TY for this, and the quick feedback.

We'll figure out what can be done here.....................

[pluto00987]

This is a direct result of #871 and is problematic indeed

To elaborate on what OP stated, it's doing two wrong things IMO:

1. Storing the python.interpreterPath setting at the workspace scope directly, without regard to setting hierarchy. In theory, if there was a reason to set a 'default' setting, it should be at the highest level, not the lowest. But also...

2. Storing the setting at all. This defeats the whole purpose of 'dynamically' detecting it. Once it's stored, it will (should?) no longer change dynamically as expected/desired. This is the setting description for the default (ie empty) value (use Python from PATH). Now there is no way to leave it empty as it's force-populated on first run with a static value.

Pulling the interpreter path dynamically from the python module makes good sense, but this implementation is flawed.

[haydenseitz]

The ms-python.python extension went through the same issues: https://github.com/microsoft/vscode-python/issues/265, https://github.com/microsoft/vscode-python/issues/2125, https://github.com/microsoft/vscode-python/issues/2126.

From this blog post, it seems the solution was to no longer store interpreter path in workspace settings, but to store in "internal storage". More info can be found here and here

[aradalvand]

This is so, so annoying, and wrong. Please fix it already.

@priyamsahoo Could you take a look at this?

[nandac]

I would be interested in having this fixed too.

[naa0yama]

I tried to work in a Multi-root Workspace today and realized that I couldn't ansible-lint. I would like it fixed soon. It's stressful because I can't write the full path when I'm using it as a team....

[priyamsahoo]

This will surely be fixed in the coming updates of the extension.

[ja1den]

I've found that if I set "ansible.python.interpreterPath": "python" in my user settings, the extension no longer modifies the workspace settings.

In my case, python is the same as python3.

[netopsengineer]

Is this setting relevant in the context of using an Execution Environment, since the extension balks at for instance not having ansible-lint in the EE, and of course you have ansible-core and python in the EE, but if you try to leave this setting blank, it constantly tries to set it, or shows a yellow warning at the bottom of VS Code asking you to select an interpreter. Is it required when using an EE? The strange behavior listed here makes me wonder if I'm actually using the EE, or something locally when it decides to modify my settings.json in the workspace, and is documented as being pertinent to finding ansible or ansible-lint in a venv, which is not in use here, since it would be found in the EE.

@ganeshrn any feedback here?

[sgreiner]

May I also request to fix "ansible.python.interpreterPath" to accept relative path like

• "./.venv/bin/python"
• ".venv/bin/python" and to also to work with vs code variables "${workspaceFolder}/.venv/bin/python" (currently not substituting anything)?

The current behavior breaks git managed ansible project where more than one person is working on....

[antonc42]

I also have the same workflow and the same problem as @sgreiner. We use a git-managed Ansible repo and started having an issue with the extension re-writing the value of "ansible.python.interpreterPath" in the ".vscode/settings.json" file. Having the relative path of ".venv/bin/python" used to work, but no longer does. I also tried "${workspaceFolder}/.venv/bin/python" without success.

I was able to work around the problem by setting "python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python3", then having everyone run git update-index --skip-worktree .vscode/settings.json. It is not ideal since changes to the file can no longer be tracked, but it does work to allow the extension on each person's machine to write into the file without affecting git. The git update-index command would also have to be run every time someone else cloned the repo.

[sgreiner]

Today I installed ansible extension v24.5 and the situation did not improve. Unfortunately, it got worse.

• "ansible.python.interpreterPath": "${workspaceFolder}/.venv/bin/python3" is still ignored.
• relative Path like "ansible.python.interpreterPath": "./.venv/bin/python3" also don't work.

But now, probably based on https://github.com/ansible/vscode-ansible/pull/1167 the (git versioned) file WorkspaceName.code-workspace is even changed for each user differently, if setting python.defaultInterpreterPath to e.g. "${workspaceFolder}/.venv/bin/python3". I looked at that PR before it was merged and did not notice the use of the wrong variable myself unfortunately.

So in the end, the tracked file WorkspaceName.code-workspace gets changed for every user, and everyone has a different line in it UserOne: "ansible.python.interpreterPath": "/home/userONE/ansibleproject/.venv/bin/python3" UserTwo: "ansible.python.interpreterPath": "/home/userTWO/ansibleproject/.venv/bin/python3" UserThree: "ansible.python.interpreterPath": "/home/userTHREE/different/location/ansibleproject/.venv/bin/python3" This is unmaintainable under version control. gitignoring this file is no solution, as the pure purpose of existence of a .code-workspace file is to have a file with project settings for everybody. (in contrast, the .vscode folder is for .gitignore and should only contain local stuff).

The desired config should have ${workspaceFolder}/.venv/bin/python3 literally in the WorkspaceName.code-workspace file and this line should NOT be changed, so it can be literally committed like this for all developers. The interpolation of ${workspaceFolder} within ansible.python.interpreterPath (not python.defaultInterpreterPath) should happen at runtime and never change any .code-workspace file's content.

[antonc42]

Thank you for the work to make ${workspaceFolder} functional!

However, I also just tried extension v24.5 and @sgreiner is correct, it doesn't seem that the problem is entirely fixed. "ansible.python.interpreterPath" is still modified in the .vscode/settings.json file. The desired outcome is that the extension only reads this setting and doesn't modify it in the file. It seems like the extension reads the setting, resolves the absolute path to the python interpreter, then writes that absolute path back to the file.

Thanks again for all the hard work, and for being responsive to community input!

[mark3apps]

Same issue for me as @antonc42 is mentioning. This is hugely problematic for any repoe where I have multiple people working out of it. Please fix this.

[TheMysteriousX]

This seems to have gotten worse in a recent release, previously it just seemed to be setting the value when VScode is started, now it's being set at odd intervals.

Especially problematic as we're running a mixed Mac/Linux environment, so when it does get accidentally commited it breaks some of the teams repo's until it's fixed.

[sebastianreloaded]

I hope https://github.com/ansible/vscode-ansible/pull/1397 fixes this?

[antonc42]

It doesn't appear to be fixed. I switched to the pre-release version v24.9.320163 and it is still happening. I'm not entirely sure this pre-release version contains the fix, but there is also this comment on the fixed issue: https://github.com/ansible/vscode-ansible/issues/1396#issuecomment-2183763627

[garymm]

https://github.com/ansible/vscode-ansible/pull/1397 did not attempt to fix this and I don't think it did.

[TheMysteriousX]

Updated the extension today, #1397 is indeed not a fix for this issue.