On 21.11.2016 14:15, Christian Heimes wrote: > 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?
Can we agree that it would be much better to get rid of platform depedency in client libraries and be done with this philosophical debate? -- Petr^2 Spacek -- 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