-
Notifications
You must be signed in to change notification settings - Fork 667
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
Add internal_names rule which flags usage of internal names in collections that must not be used #2572
Conversation
e2fd000
to
cd56c1a
Compare
The cisco.nxos |
That is really interesting because we had a chat last week with others related the same question: which form should be considered the normalized one. In our context it was more about which auto-complete value should be advertised by our language server, as we clearly wanted to avoid showing duplicates.
My impression was that "3" was the winning option and that is exactly the opposite of this rule. I need to ping @bcoca @sivel @cidrblock @ganeshrn for input on this as we want to be sure we give only one recommendation everywhere, at least one recommendation for specific environment obviously, as collection version and ansible own version might impact that. |
The fact that a few collections have decided that their use of subdirectories is not a feature, and are not subject to backwards compat sounds like the exception to the rule, and not a general recommendation. I'd actually state that the decision by these collections to not consider the real FQCN a feature, and not subject to backwards compat is the real bug here. If a collection were to move a plugin from a subdir, it should be adding redirections with deprecations. There are use cases where this could be preferred even, and seeing as though this is an actual feature of ansible-core, we should not discourage its use. |
To clarify 'internal names' is not a feature in ansible-core, we allow 'aliases', for many reasons (rename/moves, deprecation, etc) and this is a generic feature for all collections. The 'canonical' name for a plugin should be the name that it resolves to when loading, while the rest of names are either intermediate or parallel loading paths. |
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
f812899
to
a666034
Compare
For example, the FQCNs
community.general.system.sudoers
andcommunity.network.network.edgeos.edgeos_facts
should never be used for actions, since they are internal to the collection and can even change in bugfix releases.