Skip to content
This repository has been archived by the owner on Jun 10, 2024. It is now read-only.

Public Ansible Core Meeting Agenda - Novembre 2021 #635

Closed
bcoca opened this issue Nov 2, 2021 · 9 comments
Closed

Public Ansible Core Meeting Agenda - Novembre 2021 #635

bcoca opened this issue Nov 2, 2021 · 9 comments

Comments

@bcoca
Copy link
Member

bcoca commented Nov 2, 2021

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
Copy link
Member Author

bcoca commented Nov 2, 2021

Goneri (moved from last month due to PTO)

@felixfontein
Copy link
Contributor

felixfontein commented Nov 9, 2021

  • Validate some markup in documentation in validate-modules 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 Fix broken M() refs 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
Copy link

lilatomic commented Nov 11, 2021

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 Type Annotations in ansible-core 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

@felixfontein
Copy link
Contributor

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants