[Freeipa-devel] Splitting out ipaldap

[Petr Viktorin]

On 04/20/2015 08:30 AM, Jan Cholasta wrote:
> 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].

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

Well all the more reason to not create a DN/x.500 library from the 
current code.

> IMO we should do that for Python 3 and get rid of the
> python-ldap dependency at the same time.

Removing the dependency, or rather making ipaldap depend on a new 
C-based DN/x.500 library instead, can be done at any time.
I don't think it should hold back porting to Python 3.

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

I can also code it now. But I want to stay well away from breaking 
something on Python 2. A comment mentions isinstance(x, dict) being 
used, and I'd like to deal with cases like that as part of the porting.

-- 
Petr Viktorin