<div dir="ltr">Let's discuss this particular topic a little bit.<div><br></div><div>So I dedicated some time to make avocado self tests to run on macOS (see <a href="https://github.com/avocado-framework/avocado/pull/1834">https://github.com/avocado-framework/avocado/pull/1834</a>). This would be a first step to make macOS (new name of what was known as Mac OS X) a 2nd tier supported platform. This would interesting from a project health perspective since attracting macOS developers would expand user base and mind share.</div><div><br></div><div>Now, some of the avocado.utils.process APIs (example, get_children_pids) rely on executing 'ps' as a subprocess. We implemented those functions contradicting our own rules of avoiding relying on subprocesses, but it was the pragmatic choice at the moment.</div><div><br></div><div>macOS does have coreutils, but they all come from BSD, not GNU. The macOS version of 'ps' does not support the command line arguments that make the APIs to return the correct values. It stands to reason that, if we want to make avocado more portable among platforms, we should look for, well, more portable implementations.</div><div><br></div><div>For that particular case, the excellent 3rd party 'psutil' library gives us all the facilities implemented in a portable way so that it would just work under macOS (and possibly other systems). Summarizing the choices:</div><div><br></div><div>1) Use 'psutil' but then introduce an EPEL dependency on RHEL platforms. I know some of the groups using avocado have been pushing for a core program that does not rely on EPEL, so for those guys, that solution is a no-go.</div><div><br></div><div>2) 'borrow' the psutil implementations and put them in avocado, which is frowned upon by Fedora and RHEL and pretty much every distro packager ever. I don't like that idea.</div><div><br></div><div>3) Remove the offending APIs. That would be a valid solution, although capping existing functionality is not something that I fancy. We are still with a liability of having avocado libs relying on parsing external subprocess outputs, which is bad for a number of reasons and it should be addressed at some point.</div><div><br></div><div>4) Simply say the APIs are not supported on macOS. It's also valid but then it would be interesting to start delimiting linux specific APIs to a namespace (think avocado.utils.linux, avocado.utils.darwin, avocado.utils.nt) to make things clear from the get go.</div><div><br></div><div>5) Forget about the whole 'support non-linux' idea.</div><div><br></div><div>Let me know your thoughts on the subject.</div><div><br></div><div>Cheers,</div><div><br></div><div>Lucas</div><div><br></div><div><br></div></div>