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

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to