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