[Freeipa-devel] Design document: Integration Improvements

[Jan Cholasta]

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.

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.


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


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.


Honza

-- 
Jan Cholasta