Hi Thomas, Yep, dockering or AWSing a bunch of test cases was kind of what I was thinking - I just didn't want to waste the time if the approach wasn't on the right path :)
Regarding platform.system() - according to the documentation, yes, they are standardized. Looking at their source code, platform just calls uname and returns the first element of that array. The uname method is... complex. But looking through it the values appear to be co-erced in some cases into a canonical one, eg Windows, Java, etc. It's not clear if Darwin/MacOS are canonicalised, and there's some confusion about whether SunOS always ends up as Solaris... and there's some odd ones like Rhapsody and IRIX etc that are sort of handled... and the rest I guess are just left as-is self-reported? Anyway, now I know this is an acceptable path to take, I'll try and get some time to organise test cases and make sure they pass basic sanity checking on those various OSes. Regards, Jon. ___________________ Jon Marnock [email protected] On Tue, 16 Apr 2019 at 12:10, Thomas Keffer <[email protected]> wrote: > The pastebin version looks reasonable. I don't have a problem with the > dictionary mapping to an appropriate function, provided that the OS names > have been standardized. Have they? > > Definitely needs to be tested. The easiest is to set up a bunch of VMs (or > Docker boxes) on your development machine and run through your algorithms. > Tedious, I know, but there is no other way that I know of. > > -tk > > On Mon, Apr 15, 2019 at 7:01 PM Jon Marnock <[email protected]> wrote: > >> Hi, >> >> So firstly, I know it's been mentioned before and there's a reluctance to >> add dependencies on external modules for this, but there do appear to be >> some that would be very useful and give broad support for OS uptime >> reporting, eg: >> >> https://pypi.org/project/uptime/ >> >> That said, if we want a dependency-free subset of those things here based >> on OS switching as suggested above, would something like this approach be >> in the right direction? >> >> https://pastebin.com/fUVHEJr3 >> >> I get that the exception handling in that code is... rudimentary :) Happy >> to take suggestions for improvements (this is literally the first time I've >> ever tried to write python, so I'm sure I'm making lots of mistakes). >> >> In any event, I've tested it only on OpenBSD. The MacOS and Linux code is >> basically just copied and pasted (but again, I haven't tested it), and the >> NetBSD stuff was just copied and pasted as well with one small change: I >> noticed that it looks as though the same mistake was made in that code that >> I made: assuming an int return type for the sysctlbyname, whereas the doco >> indicates it does in fact return a timeval, which is also a c_longlong and >> then a c_long (ultimately). Both of ours worked presumably because we >> aren't in the unix epoch yet and either python was just overallocating >> memory which wasn't used, or was internally converting the return type into >> the smaller datatype. >> >> In any event, since I'd figured out the structs thing for the OpenBSD >> version, I ported that change back to the NetBSD - but obviously, someone >> with NetBSD will need to test that it still works correctly. >> >> I also peeked at one of those other libraries for how they did windows >> uptime - consistent with the other cut-down versions for the other OSes, >> I've included an untested cut-down version of how they do it that should >> work (possibly with a little tweaking) with more recent windows versions. >> Again, this will need testing. >> >> Thoughts? >> >> Regards, >> Jon. >> >> On Tuesday, 16 April 2019 08:09:21 UTC+10, Tom Keffer wrote: >>> >>> I agree: stacks and stacks of try / except statements can lead to indent >>> hell. >>> >>> One way to cut that down is to use functions. Each function would try / >>> except a set of related operating systems, and if none of them work, raise >>> NotImplementedError. The main function would then just have to catch >>> NotImplementedError. It will cut down the bulk. >>> >>> -tk >>> >>
