[Freeipa-devel] Splitting out ipaldap

[Petr Viktorin]

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