[Freeipa-devel] [WIP] ipapython/iputil.py refactoring for better cross-platform support

[Alexander Bokovoy]

On 20.07.2011 21:59, John Dennis wrote:
> On 07/20/2011 01:30 PM, Alexander Bokovoy wrote:
>> Actual<platform>  value is substituted using top-level Makefile's
>> SUPPORTED_PLAFTORM= variable (defaults to 'redhat', can be redefined
>> without modifying Makefile, in package building scripts, for example)
>> and then ipapython/services.py is generated from ipapython/services.py.in
> 
> Why can't the platform be resolved at runtime instead of part of a
> static build? That would be more flexible wouldn't it? We would ship the
> same code in each release which is a win for robustness and
> reproducibility. I guess I don't see the advantage of static build time
> code selection in a language like Python.
The reason for it is that runtime platform selection simply gives no
advantages in IPA case. A typical deployment is a distribution of a
prepared package to multiple clients, not building freeipa code on every
single client with a purpose to run ipa-client-install on it. At this
point we already know the platform. Replacing this knowledge with
run-time detection that can go wrong and would require more extensive
knowledge and effort to verify that platform is detected reliably isn't
really productive.


> Earlier you said:
> 
>> I'll try to avoid using package management tools
> 
> but since you're relying on build tools you're implicitly relying on
> package management tools.
I was talking about using package management tools in runtime where one
would incur computational costs. In proposed solution I'm trying to
delegate a decision point to a package maintainer or a developer which
already knows a platform s/he works with. There is no runtime overhead
at all and single

make SUPPORTED_PLATFORM=foobar

would be equivalent to already utilised

make



-- 
/ Alexander Bokovoy