Dne 4.3.2017 v 13:36 Lucas Meneghel Rodrigues napsal(a):
Great, btw we already have some mac users, they are just not running selftests and not using features that are broken...Let's discuss this particular topic a little bit.So I dedicated some time to make avocado self tests to run on macOS (see https://github.com/avocado-framework/avocado/pull/1834). 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.
Please don't. The core should have as little dependencies as possible, unless there is a great benefit in having it (stevedore).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. 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. 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: 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.
We already do that by using `ps`, we can extend it of a different backend (`/proc` or the psutil)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.
Depending on `ps` output is a standard for decades (not just for Avocado). Although in some cases we might find a better/simpler/faster way.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.
Yes, but not for things like `process` as it's needed everywhere. For `process` I could imagine different backends (similarly to virtio_console_guest.py which supported windows and linux version)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.
5) Forget about the whole 'support non-linux' idea.
Definitely not, we already have (production) users using Avocado on Mac.
Let me know your thoughts on the subject. Cheers, Lucas
Looking forward to `mac` variant in Travis... Lukáš
signature.asc
Description: OpenPGP digital signature
