[Avocado-devel] Make some avocado.utils.process APIs compatible with macOS

[Lukáš Doktor]

Dne 4.3.2017 v 13:36 Lucas Meneghel Rodrigues napsal(a):
> 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.
>
Great, btw we already have some mac users, they are just not running 
selftests and not using features that are broken...

> 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.
Please don't. The core should have as little dependencies as possible, 
unless there is a great benefit in having it (stevedore).

>
> 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.
We already do that by using `ps`, we can extend it of a different 
backend (`/proc` or the psutil)

>
> 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.
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.

>
> 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.
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)

>
> 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áš

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 502 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/avocado-devel/attachments/20170313/8710ada0/attachment.sig>