How to handle module dependencies during development?

Hi folks - We had some interesting discussion in a recent docs issue that seemed appropriate to bring here and widen the audience.

We don’t really talk much about how a module developer handles dependencies, other than I short blurb here.

So the question is - How can we put more detail in this section to help developers in this scenario ?

  • Should we more strongly suggest that developers avoid dependencies?
  • Are the recommendations other developers have that we can add to the docs for those cases where you Have to install dependencies somehow on the target system?

Core has had very strict restrictions on module requirements, but this was in an effort to make the CLI installable and usable in as many contexts as possible.

  • Requirements should be clearly stated in documentation (requirements: key) and checked at runtime, return concise but complete error to user ’ <X lib/binary> is missing on <this python/PATH> on this '. module_utils has a missing_lib function to help with that.
  • Avoid using non Python core libraries
  • Build into module_utils, even if it means creating some duplication with existing 3rd party libs. ( vs requests)
  • If forced to use 3rd party lib, try to depend on as old a version as possible (OS package manager friendly).
  • If the functionality used is version dependent, both check in code and clearly state in the requirements:.
  • Exceptions where allowed when dealing with well established required 3rd party lib for a service. For example boto for aws.

While most Python devs will say ‘just use pip’ , this is not possible in many environments, also the scrutiny, security and compatibility tests done on OS packaging level have been wider and more comprehensive than what language package management services normally do. Which makes a lot of users favor the OS packages over libraries you download from a 3rd party service. And while this approach has changed, specially with the advent of containers, the rules in many places have not, specially for big enterprise and govt, which are very slow moving targets.

I post this not to say ‘this is what you should follow for your collection’ but to explain the rationale behind these rules for core. This probably does not apply to you unless you are targeting ‘the slow movers’, but it is also a baseline I would suggest for the more systems and reliability minded.