[Freeipa-devel] Design document: Integration Improvements

[Christian Heimes]

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?

Christian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20161121/dcff018e/attachment.sig>