I have a lot of mixed thoughts on this one, I've always encouraged module authors to avoid requests due to 1.x but even 2.x version incompatibilities, but I was unaware we banned them until this thread was started (we should update the docs). Even though the development of 'requests' has been much more stable for the last few years, the 'installed base' has a very long memory and not everyone can update to the latest from pip, which is what most developers target/test. This is also why I insist on 'version checking' when i see `import requests` on any module or it stated as a dependency .. the same goes for docker.py, anyone that has looked at those modules can see the proliferation of version comparison statements. There are a few libraries that fall into this category, mostly due to rapidly changing landscapes in tech.
Another thing to consider is that the controller tends to be much newer OS/Software than the targets (user workstation vs servers) and that even those versions might differ vastly, so modules/plugins that require requests on the controller should be less problematic than those that execute on the remote target. We already have plenty of modules/plugins that depend on requests, but mostly due to depending on an API specific library that uses requests internally. I'm not a fan of banning, but I can see @sivel's point on avoiding unnecessary dependencies when we have alternatives that cover the same needs. For those that were not already using related tools and had the libraries already installed, installing new dependencies manually is already a burden, I would prefer not to add to it. Should we then expand this criteria to any/all libraries? What is the threshold? Taken to the absurd extreme, every library can be eliminated as a dependency until we get into C bindings and such .. even then we can work around those by using 'pure python' implementations. Whatever we decide, we should also clearly document it, not just add a check that makes it fail in CI. In the end, I'm fine with removing the ban. I would still 'strongly recommend' to any authors on review to use the existing alternative, specially if they want to be included in Ansible's distribution. And, if they cannot avoid it, be very clear about the versions required, both in code and in docs. ---------- Brian Coca -- You received this message because you are subscribed to the Google Groups "Ansible Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to ansible-devel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
