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:
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
+1
* High-level classes for schema elements
* Support different schema styles (LDAPv3, AD), or at least make it
possible
Here I'm inclined to just say the schema API isn't done.
* High-level class for filters
As long as we still accept filters as text, I don't see any backcompat
problems here. (Assuming we don't expose the current filter-making
helpers, which I'd rather kep IPA-specific, anyway.)
* 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
Those two should be possible to add while keeping compatibility.
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.
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.
- 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.
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.
--
Petr Viktorin
--
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
