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