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
Description: OpenPGP digital signature