[Freeipa-devel] Splitting out ipaldap

[Jan Cholasta]

Dne 16.4.2015 v 09:18 Petr Viktorin napsal(a):
> 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:
>>>>>> 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.
>>
>> 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.

OK.

>
>>>>    * 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.
>>
>> I don't think I want the paged_search argument of find_entries to be
>> supported.
>
> Then I'll document it as unsupported.

OK.

>
>>>>>>> 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.
>>
>> 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 would rather get rid of the python-ldap dependency.

We talked about rewriting DN in C, because long-term we can't keep 
working around the performance issues caused by DN being implemented in 
Python. IMO we should do that for Python 3 and get rid of the 
python-ldap dependency at the same time.

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

Wouldn't it be easier to use a custom MutableMapping for both? I can 
code it now if you want, and replace it with my currently WIP stuff later.

-- 
Jan Cholasta