Deprecate vscode-ansible in favor of yaml extension

[bristea]

Summary

vscode-ansible was a good addition when it was created 3 years ago but it become unmaintained and cluttered with bugs that make it usability negative.

Please officially acknowledge that this extension is deprecated and can easily be replaced by a more feature reach alternative which is https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml

Expected Results

Deprecation of vscode-ansible

Details

The contributions graph is a proof of lack of maintenance.

If a bug like #261 that indicates that the extension is not able to load even the most basic ansible command "set_fact", has ~60 confirmations but is not addressed is another way to express the reality.

Instead of confusing vscode users looking for Ansible related extensions in Marketplace with an unmaintained extension, the team should update the Marketplace listing to change status to deprecated.

[GitMensch]

@bristea redhat.vscode-yaml doesn't say anything about the support for ansible. Are you sure that everything included here for ansible is also included there? If yes it really would be good to mention this at least in its README and keyword list.

[moltar]

There seem to be some issues regarding Ansible there, but I am not seeing any code mentions of Ansible 🤷🏼‍♂️

https://github.com/redhat-developer/vscode-yaml/search?q=ansible&type=issues

[JPinkney]

Hi! I'm one of the maintainers for VSCode-YAML. We don't have any Ansible specific code, we rely on having the user set a JSON schema and associate it to their YAML files. This will grant you the ability to have hover, completion, validation, etc.

The way you can do this is by associating a schema to a glob pattern in VSCode-YAML: https://github.com/redhat-developer/vscode-yaml#associating-a-schema-to-a-glob-pattern-via-yamlschemas.

You can use one of the Ansible schemas that's available on the JSON Schema Store:
ansible-role-2.9
ansible-playbook
ansible-inventory
ansible-collection-gallary

[ssbarnea]

I am really curious how vscode-ansible determines what is an ansible file or yet another YAML files unrelated to ansible. Maybe they already addressed that conundrum.

The "we rely on having the user set..." approach is sadly guaranteeing a poor default user experience, mainly the awesome vscode-yaml extension is unable to help any Ansible users with its default setup (same applies for a wide range of other YAML config files).

I think that what we should all aim to achieve here is a behavior where freshly installed extensions do not need tuning in order to cover for most common use case.

That is not an easy issue to address because YAML spec still lacks an official schema marker. Luckily, if you read the ticket you will find an workaround specific to vscode. While this workaround may prove practical to use for random tool config files, it is practically close-to-impossible to apply to repositories containing more than a couple of Ansible files, as it would require user to add a comment line to each ansible file.

It is quite common to have hundreds of such files in a single repository and you would have to add different header for each file-type supported by ansible (6 or more already). The worst part being that it would be a vscode specific file, and not every developer is using vscode, and I am sure that even if someone proposed adding these headers on open source projects, there will a big clash from other core reviewers arguing against it as being "developer specific config".

For example OpenStack has a policy for not allowing developer editor specific excludes in .gitingore files. It may sound weird but think at scale and noise: hundreds or repos, thousands of contributors using likely hundreds of editors. The amount of churn needed to maintain these would affect projects workflows. I only mentioned this in order to underline the problem of not having working defaults.

@JPinkney I wonder if it would be possible for vscode-ansible to rely on vscode-yaml and help it recognize ansible files easily, without manual configuration. Is such hook possible to implement?

Maybe we should also investigate the possibility to transfer the maintenance of this extension to https://github.com/ansible-community where I suspect there are many people with a strong interest in making this extension awesome too. My impression is that could be a chance to revive this effectively dead extension.

[GitMensch]

@ssbarnea
The referenced issues has a note that there's work on a yaml specification change which allows the schema to be included in the yaml "header". I'm quite sure (form the dev response in the same issue) that VSCode-YAML would pick this up when it is available. If ansible and others don't error on that "header" (a comment would guarantee that) then you'd have the option of either using the schema configuration (which may be useful if all your configs are named similar enough, ike travis.yml, appveyor.yml or are in a common folder like ansible) or adjust each of your yml files with the new spec format.

I am really curious how vscode-ansible determines what is an ansible file or yet another YAML files unrelated to ansible

As far as package.json looks - it doesn't. It defines a new language identifier "ansible" which extends "yml". If you want travis.yml/appveyor.yml not be "recognized" as ansible then you have to switch its language identifier (either one-time or via vscode setting).

[JPinkney]

I wonder if it would be possible for vscode-ansible to rely on vscode-yaml and help it recognize ansible files easily, without manual configuration. Is such hook possible to implement?

The extension point for this has existed for around ~3 years at this point, VSCode-Ansible just doesn't use it. vscode-kubernetes, vscode-tekton, vscode-knative and a few more are all using it though. Essentially what happens is every time you make a completion/hover/validation request VSCode-YAML will ask other VSCode extensions if it recognizes the content. If they do then they send back a schema to use with the request. That way users don't have to set the schema themselves. VSCode extensions using the API are then responsible for determining if the content in the file is relevant to their application and sending back the correct schema

[GitMensch]

That sounds very useful. This extension (or a fork of it) may drop its own yaml file handling, use the extension point (adding a dependency on the vscode-yaml and a "logic" does this look like ansible) and keep all its action handling.

To "answer" the original question/request of deprecating this extension in favor of vscode-yaml: that's not useful as this extension has al the ansible specific actions like (run in ...) which are not relevant for the general purpose vscode-yaml extension.
Combining both would lead to "full recognition [by ansible schema] and the features available here, without the need to manually setup yaml schemas - and even would (if the schema is kept here or in a fork up-to date) allow the schema to be included and passed on to vscode-yaml (removing the need for it to download it, which may not even be possible for different environments behind a proxy/firewall).

As @bristea called for the deprecation: do you think you could get the fork running if @yungezz, which is still active at GitHub, don't plan to update this repo? (Is that the case btw?)

[ssbarnea]

@GitMensch @yungezz I observed that few months back a "RETIRED" was squeezed inside the extension description but I still see it listed in the marketplace and not only that but is still listed as first result on any search for "ansible". That was indeed a good move.

What I do not understand is why that extension was not just unpublished from the marketplace. Its current state does not really motivates still keeping it listed, especially as it manages to endup being "no1" search result, even if is not of any practical use.

The newer https://marketplace.visualstudio.com/items?itemName=zbr.vscode-ansible keeps adding new features and welcomes others to join. First version was published in January and was listing as no14, now is listed at no3.