[Freeipa-devel] Design document: Integration Improvements

[Petr Spacek]

On 21.11.2016 14:15, Christian Heimes wrote:
> On 2016-11-21 13:31, Jan Cholasta wrote:
>> Hi,
>>
>> On 11.11.2016 15:25, Christian Heimes wrote:
>>> Hello,
>>>
>>> I have released the first version of a new design document. It describes
>>> how I'm going to improve integration of FreeIPA's client libraries
>>> (ipalib, ipapython, ipaclient, ipaplatform) for third party developers.
>>>
>>> http://www.freeipa.org/page/V4/Integration_Improvements
>>
>> 3.1 API for local configuration directory
>>
>> "Both approaches have some disadvantages. A user must repeat the -e
>> option in every call to ipa or create a shell alias. It's both tedious
>> and error-prone."
>>
>> This is pretty subjective. I don't think it's error-prone at all, since
>> it is explicit and you always know what confdir value will be used in
>> the ipa command just by looking at its arguments, as opposed to the
>> environment variable, which makes the configuration implicit and
>> depending on *sane* environment and is equivalent to preferring global
>> variables to function arguments in Python code.
> 
> It's not implicit. The env var has to be set explicitly just like you
> have to use -e confdir explicitly in every call.
> 
>> That being said, this whole section is filled with one-sided "facts" and
>> simply ignores everything else, which might lead the reader to believe
>> that the environment variable is something required, while it is in fact
>> just a nice-to-have convenience feature. A good design should include
>> both sides of an argument, even if you don't agree with one.
>>
>> BTW, shell alias works perfectly fine in your virtualenv example above
>> in the design.
> 
> No, it does not work perfectly fine. By default shell aliases are
> limited to interactive shells. My proposal also works with Python
> subprocess module, a C program with execve(), Makefile, Ansible local
> command, non-interactive shell script...
> 
>> 3.2.1 Build and runtime requirements
>>
>> How are we going to detect and report missing runtime dependencies?
>> Currently if they are not installed, the code will fail at random places
>> during execution with an often cryptic error message. I think this is
>> unacceptable, and since there is no way specify external dependencies
>> using setuptools (right?), it needs to be done in our code during
>> package import (or other suitable place).
> 
> Instead of detecting missing dependencies, we document requirements and
> treat users as adults. Runtime checks are a performance issue. Since
> wheels don't execute code at installation time, we can't check for
> missing dependencies during installation.
> 
>> 3.3 ipaplatform auto-configuration
>>
>> I'm not sure if guessing platform from ID_LIKE is really a good idea. It
>> might work fine for centos -> rhel, but in general we can't really
>> assume it will always work, as the platforms listed in ID_LIKE might not
>> be similar enough to the one in ID. I would rather add an ipaplatform
>> subpackage for every supported platform (including CentOS) than depend
>> on error-prone guesswork.
> 
> Can you show me a real-world example for your statement that ID_LIKE is
> error-prone?
> 
> Your proposal doesn't scale. There are tons of Debian spins with their
> own ID. For example my Raspberry Pi has ID=raspbian and ID_LIKE=debian.
> Do you want to maintain an exhaustive list of all Debian and Ubuntu
> variants?

Can we agree that it would be much better to get rid of platform depedency in
client libraries and be done with this philosophical debate?

-- 
Petr^2 Spacek