On 11.11.2016 15:25, Christian Heimes wrote:
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.
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
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.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code