[Freeipa-devel] Design document: Integration Improvements

[Jan Cholasta]

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.

Yes, you need to set it explicitly, but then it is implicitly inherited 
by the command. And just like with global variables, you might have a 
hard time tracking down where it was set and why if you din't set it 
yourself, especially if you are a casual user and not a developer like us.

>
>> 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.

Last time I checked virtualenv provided an interactive shell.

> My proposal also works with Python
> subprocess module, a C program with execve(), Makefile, Ansible local
> command, non-interactive shell script...

... which are all more or less write-once, so the env variable provides 
very little benefit over the command line option.

>
>> 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.

We do all kinds of runtime checks in our commands - are you saying we 
should just remove them all, because the users are 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.

In other words, we will provide broken packages in PyPI, at least 
compared to our downstream packages. Is this really the normal thing to 
do for PyPI packages with external dependencies?

>
>> 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?

Yes, I'm aware of that, I was hoping we could find some sort of compromise.

>
> Christian
>


-- 
Jan Cholasta