On 04/15/2015 08:30 AM, Jan Cholasta wrote:
Dne 14.4.2015 v 19:21 Petr Viktorin napsal(a):
On 04/14/2015 06:18 PM, Jan Cholasta wrote:
Dne 14.4.2015 v 17:50 Petr Viktorin napsal(a):
On 04/14/2015 05:22 PM, Jan Cholasta wrote:
Dne 14.4.2015 v 16:38 Petr Viktorin napsal(a):
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  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
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
or "ipaserver"; additionally I want to release it on PyPI .
Note that I don't consider ipaldap API stable and don't want to put
effort in maintaining backward compatibility when something needs
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
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
Here I'm inclined to just say the schema API isn't done.
It will affect how syntax mapping is done, so it depends on whether
syntax mapping is exposed or not. There are also some schema-related
LDAPClient methods (like get_allowed_attributes) which will be (re)moved
when the schema API is done.
I think putting warnings around the unfinished parts would work.
* Some better way of doing "extended" operations (paged search, deref
* Support different transports (LDAP, local LDIF file), or at least
make it possible
Those two should be possible to add while keeping compatibility.
I don't think I want the paged_search argument of find_entries to be
Then I'll document it as unsupported.
My general plan is:
- Move ipapython.dn -> ipaldap.dn (keeping ipapython.dn importable
DNs are not strictly LDAP specific, so I would rather move
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
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.
No. Any vaguely defined collection of generic utilities needed in a
project is really a single-purpose package. Nobody likes pulling in a
bunch of unrelated stuff because of one particular thing they need, and
without a scope the amount of unnecessary stuff grows without bound.
I'd be OK with an "ipadn", if you can manage the overhead of a package.
IMO "ipadn" is just too specific. I guess we can use X.500 as scope,
since the basic types like DN or OID are defined in X.500, and put it in
"ipax500". Does that sound OK?
It might make sense conceptually, but do you have a use case? Some
software that would want to depend on python-ldap (since that's what DNs
depend on), but couldn't also bring in ipaldap?
I don't see the benefit, so I don't really want to do this myself.
- Move CIDict to ipaldap.cidict. For Python 3, I'd really like to
replace this with something based on collections.MutableMapping,
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.
I was thinking the Python 3 boundary is a good point to switch, since
stuff will be breaking anyway. I can import the new one under py3, and
keep the old one for py2.
I'm a bit lost here, what do you mean by "new one" and "old one"?
Use the existing (old) CIDict under Python 2, and a new one based on
MutableMapping for all Python 3 code.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code