TL;DR Should ipaplatform be dynamic or fixed at build time?
Last November a ticket was proposed to change the platform detection from being done at build time (via autoconf) to runtime in ticket https://pagure.io/freeipa/issue/6474
This was inspired somewhat by http://www.freeipa.org/page/V4/Integration_Improvements
This consisted of two main proposals:
1. Let one specify the location of the IPA configuration so that clients not enrolled via ipa-client-install can still work (e.g. you can use it completely as non-root). 2. Make ipaplatform dynamically detect the underlying OS for use in PyPi.
Discussion on this proposal happened in thread https://www.redhat.com/archives/freeipa-devel/2016-November/msg00391.html
Discussion continued in the PR, https://www.redhat.com/archives/freeipa-devel/2016-November/msg00887.html
From my reading no firm decision (beyond pushing the code) was made except that there was resistance to both of these proposals. The relevant part for now is ipaplatform. Moving around a bunch of code ended up being quite disruptive internally and wasn't ultimately completely successful, see https://github.com/freeipa/freeipa/pull/1036
The boat has sailed on moving the code around but the moves were disruptive to anything that was using ipalib (another discussion altogether is the supportabilty/stability of ipalib).
What we're left with is that the PyPi build is currently broken and has been for several weeks. The current proposed fix is to duplicate values which while undesirable generally is a quick and dirty way to get PyPi working. Felipe agreed to update his PR to use a _ prefix to indicate the constants are for internal-use only. This should buy us time to work on a more complete solution.
So to me the question is dynamic vs build-time detection of the underlying OS. If one lives in the world of only OS-distributed packages then build-time detection makes perfect sense and leaves no room for error on deployed systems.
PyPi is another story though. The PyPi version doesn't ship ipaplatform at all which makes PyPi a bit of a second-class citizen. This could impact future systems like ansible that might want to deploy from PyPi, and tox which often installs its own dependencies during testing. PyPi also lets one easily install different versions of packages in different virtual environments for expanded testing without requiring root.
IMHO something needs to change. Felipe's PR has the feeling of the first of a thousand cuts. I'm in favor of runtime detection with extreme, if not ridiculous logging. The major downside of runtime detection, which wasn't discussed previously, is opaqueness: you can't tell why things are behaving as they are because the runtime choice was opaque. With copious debug-level logging I think this would be a moot point. Bugs may still occur with detection but they will hopefully be painfully obvious and easily fixable.
The main opposition to runtime dependency seemed to me to be related to handling failures gracefully. I think a hard stop with tons of output is sufficient to handle this case. All major distros already do a lot of testing pre-release which would catch any issues. There remains some risk for bleeding-edge releases that could make changes post-release.
If /etc/os-release goes away then this would have to be dealt with in the installer anyway, the impact will just be broader (and therefore likely fixed faster).
It may be worthwhile to collect /etc/os-release from as many Linux distros as possible to ensure the best level of compatibility.
A final else "Your distro is not supported" will handle things we have not encountered yet, or targeted (e.g. win32, Solaris, etc). Support for these could be contributed.
rob
freeipa-devel@lists.fedorahosted.org