ansible/community

Public Ansible Core Meeting Agenda - Novembre 2021

bcoca opened this issue · 9 comments

bcoca commented

Please leave a comment regarding any agenda item you wish to discuss. If you don't show up for the meeting, your item will be skipped. If your IRC nick is different from your Github username, leave that as well.
See https://github.com/ansible/community/blob/master/meetings/README.md for the schedule

Once an item has been discussed it should get checked off.

If you just want reviewers for your contribution try the #ansible-devel irc channel on libera.chat

bcoca commented

Goneri (moved from last month due to PTO)

felixfontein commented
  • ansible/ansible#76262 Add support to validate-modules which checks documentation markup (M(...) and some friends). This already exposed broken docs in some collections, and would have also exposed ansible/ansible#76202 if it hadn't already been fixed. (Antsibull now ignores M(...) where the content is not similar enough to a FQCN, and according to the docs team this made ~150 docs build warnings go away. A certain amount of these will likely be issues exposed by this PR.)
lilatomic commented

Type hinting in ansible-core

It was brought up that we hadn't decided how we would be hinting types in ansible-core. I think the issue is simplified considerably with ansible-core dropping support for Python versions which do not support the PEP484 type hints.

For me, the biggest advantage of type hints is that I can know what type I should expect function arguments or class attributes to be without having to trace their creation. Ansible solves complicated problems, and sometimes tracing where something is created to show which class it is instantiated from can involve moving up several classes through about a dozen functions.

Pros:

  • know the types of function arguments and class attributes without having to traverse the codebase
  • can help you spot silly errors (like forgetting to access elements of a tuple)

Cons:

  • more things to type
  • noisy
  • sometimes type hints aren't useful because of dynamic objects
  • some type-hints have compatibility issues (TypedDict is the one which comes to mind, it wasn't available in 3.6 and required a conditional import of typing-extensions)

I think we can mitigate the cons by only putting type hints where they're useful. I think a good definition of "useful" in this case is where someone thought to add them or to request them.

TL;DR: I think we should allow the use of PEP484 type hints in ansible-core

(this is my first time adding an item to the agenda, LMK if there are things I can improve)

Summary from the IRC meeting:

  • We're going to discuss this in detail on Nov 30th (the next IRC meeting that doesn't conflict with a US holiday).
  • nitzmahone is going to post a list of options with some pros and cons prior to the meeting. The proposal lives at ansible/proposals#202 - may not have a quorum at the Nov 30 meeting to discuss, but it's there for comment.

Here's a demo mattclay put together so we can discuss something concrete: ansible/ansible#76332

  • ❤️2