Dne 14.4.2015 v 17:50 Petr Viktorin napsal(a):
On 04/14/2015 05:22 PM, Jan Cholasta wrote:
Hi,
Dne 14.4.2015 v 16:38 Petr Viktorin napsal(a):
Hello!
As some of you know, I'm looking to help porting FreeIPA to Python 3.
One of the major dependencies holding this back is python-ldap, which
hasn't been ported yet. Some preliminary porting patches by Raphaël
Barrois [0] are ready and have been sent to the python-ldap list. The
python-ldap upstream has been very quiet about reviewing them so far,
but they're something for me to test against, and maybe improve.
To make the testing easier, I'd like to split out "ipaldap" to a
stand-alone package, and port it to Python 3 first.
This split will make it easier to test (since I don't have to port all
of IPA), and being able to use our generic LDAP wrappers in non-IPA
projects could maybe also invite some community participation. Also,
ipaldap unit tests are somewhat lacking, so I'll help with that.
Packaging-wise, I want "ipaldap" to be on the same level as "ipapython"
or "ipaserver"; additionally I want to release it on PyPI [1].
Note that I don't consider ipaldap API stable and don't want to put any
effort in maintaining backward compatibility when something needs to be
changed, so you might want to hold the PyPI release, or at least put a
big fat warning in some visible place.
If it's released early & often, it'll at least be visible to interested
people.
It would be nice to include a roadmap file saying what needs to change
before we start claiming API stability.
From the top of my head, in no particular order:
* High-level class for attribute values
* High-level classes for schema elements
* Support different schema styles (LDAPv3, AD), or at least make it
possible
* High-level class for filters
* Some better way of doing "extended" operations (paged search, deref
search, etc.)
* Support different transports (LDAP, local LDIF file), or at least
make it possible
My general plan is:
- Move ipapython.dn -> ipaldap.dn (keeping ipapython.dn importable for
old scripts/plugins)
DNs are not strictly LDAP specific, so I would rather move ipapython.dn
to a new ipautil package.
I'd rather not, at least until there's something that needs it (and
doesn't also depend on ipaldap). The scope of "ipautil" is far too badly
defined for such a package to be useful.
IMO generic stuff should be in a package for generic stuff. I guess it
should originally have been ipapython, but it's too fused with ipalib
ATM, hence my proposal to use a new package.
- Move CIDict to ipaldap.cidict. For Python 3, I'd really like to
replace this with something based on collections.MutableMapping, since
the semantics of subclassing "dict" aren't very well defined.
I have WIP which does just that.
Could you send it?
Not yet unfortunately, CIDict removal is actually just a side effect of
other changes, and it still needs a lot of work before it is sendable.
- Create a new module for ipaldap-specific exceptions. IPA will use a
hook to swap out this module for its own set of exceptions. (Yes, this
is a hack, but I'd like to keep ipaldap clean of IPA dependencies. A
proper solution will be quite involved, given translatable error
messages and XML-RPC numbers.)
I have given this some thought since our last conversation about this
and I think there won't always be 1-to-1 mapping between ipaldap and
ipalib errors, so IMO we should go with the usual monkey patching
approach in ipapython.ipaldap:
import ipaldap
import ipaldap.errors
from ipalib import errors
ipaldap.errors.SomeError = errors.SomeError
ipaldap.errors.SomeSimilarError = errors.SomeError
ipaldap.errors.SomeOtherError = errors.SomeOtherError
...
try:
ipaldap.something()
except ipaldap.errors.BaseError as e:
# catch ipaldap errors that weren't monkey-patched
raise errors.DatabaseError(str(e))
I don't like this idea at all; action-at-a-distance bugs caused by
monkeypatching are some of the worst bugs to have to deal with.
If someone builds a library on top of ipaldap, and then uses it in a
project that also uses ipapython, then the library would suddenly start
raising IPA-specific errors.
If you pass a collection of errors to LDAPClient to use, or even if you
subclass, or monkeypatch a specific instance, other IPAClient
instances/subclasses are not affected.
I think limiting the impact of a hack is more preferable than a somewhat
cleaner solution.
Right you are.
I don't really care how it's done as long as it's possible to make the
mapping not 1-to-1.
--
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
