In short
Today rules are about whole modules/files. This lets you write rules about the members inside them — functions, methods, attributes — e.g. 'every public function in the domain must have type hints' or 'no module-level mutable globals.'
Problem
Many rules are about members: 'public functions in the domain must have type hints', 'no module-level mutable globals', 'repository methods must be async'. ArchUnitPython can select members but only for metric thresholds, not for rule assertions.
Proposal
Promote the existing classes() / functions() member selectors into the rule API so members can be asserted on, e.g. project_files("src/").functions().in_folder("**/domain/**").should().have_type_hints(), with predicates on names, type hints, async, dunder and underscore-visibility.
Acceptance criteria
In short
Today rules are about whole modules/files. This lets you write rules about the members inside them — functions, methods, attributes — e.g. 'every public function in the domain must have type hints' or 'no module-level mutable globals.'
Problem
Many rules are about members: 'public functions in the domain must have type hints', 'no module-level mutable globals', 'repository methods must be async'. ArchUnitPython can select members but only for metric thresholds, not for rule assertions.
Proposal
Promote the existing
classes()/functions()member selectors into the rule API so members can be asserted on, e.g.project_files("src/").functions().in_folder("**/domain/**").should().have_type_hints(), with predicates on names, type hints, async, dunder and underscore-visibility.Acceptance criteria
project_files("src/").functions().in_folder("**/domain/**").should().have_type_hints()fails on an untyped domain function.