mitogen.master.ModuleFinder locates Python modules on the controller tthat can be sent to children in response to a GET_MODULE request. It also scans the found module M to identify "related modules" - a dependency tree of modules imported by M, directly or indirectly.
mitogen.master.ModuleResponder sends the found module and all related modules, proactively.
Current bugs and quirks
Ideas so far, not mutually exclusive
- Use
ast to scan for import statements
- Eliminates false negatives
- Potentially increases false positives, depending on how we define desired criteria (e.g.
import mitogen.master inside mitogen.main())
- Remove related functionality, rely on children sending GET_MODULE requests as needed
- Eliminates a chunk of fiddly code
- Reduces CPU and random disk IO on controller
- Increases number of round trips
- May increase Time To First Execution (TTFE, a term I just made up) on the child
- May increase maintenance burden wrt new Ansible releases, manually maintaining a preload list of required Ansible modules
- May make Mitogen less robust wrt to long tail of Python packages and Ansible collections
- Make related search/delivery configurable, e.g.
- Something similar to
# !mitogen: minify_safe markers
- Environment variable(s)
Refs #1242 #1324 #1239
mitogen.master.ModuleFinderlocates Python modules on the controller tthat can be sent to children in response to a GET_MODULE request. It also scans the found module M to identify "related modules" - a dependency tree of modules imported by M, directly or indirectly.mitogen.master.ModuleRespondersends the found module and all related modules, proactively.Current bugs and quirks
Ideas so far, not mutually exclusive
astto scan forimportstatementsimport mitogen.masterinsidemitogen.main())# !mitogen: minify_safemarkersRefs #1242 #1324 #1239