[Freeipa-devel] Splitting out ipaldap

[Petr Viktorin]

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.

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

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


-- 
Petr Viktorin