python-ldap-dev

1.10alpha 'release'

[David L. <dav...@cs...>]

if you look at http://python-ldap.sourceforge.net/release.php you should
be wonderstruck by a 1.10alpha "release".

this has heaps of pesky memory leaks fixed, and a package for OpenBSD.

if you have CVS access, please check out the new Build directory.. i'm not
very up on linux or other OSs, so if you want to contribute a directory there
for your favourite system, that would be great. the idea is to make a 
simple script that will build a release tarball fairly automatically.
i've had a go at a linux one - it seems to build on the sourceforge linux
server. python isn't installed on the freebsd server though, but when i
get time, i'll build it myself.

also I revamped the documentation area and will build a spiffy looking doc
using the new latex macros. but it has some glitches i notice.

so far, all that the package has is whats in Lib and the _ldapmodule.
fog, or whoever, if you want the rest to be installed sensibly, please
link it into the root Makefile.in.

comments?

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

David Leonard wrote:
> 
> if you look at http://python-ldap.sourceforge.net/release.php you 
> should be wonderstruck by a 1.10alpha "release".
> 
> this has heaps of pesky memory leaks fixed,

I assume that these sources contains the patches by Johannes.

> please check out the new Build directory..

Very fine. I will make RPMs for recent S.u.S.E. Linux.

> the idea is to make a
> simple script that will build a release tarball fairly automatically.

Hmm. I have to learn the RPM-ish things but I will send the shell
scripts.

> also I revamped the documentation area and will build a spiffy looking 
> doc using the new latex macros.

Great.

This leads to the question which things have to be done before
releasing 1.10? 

1. Testing:
I tested the version of Johannes and it seems to work. I tested all
operations (search, modify, add, modrdn, delete). Hmm, I'm thinking
about writing a Python script which implements the BLITS test suite
on a defined data set. This is a pretty boring job but would ease
testing in the future.

Can anybody else say something about how stable the current version
is?

2. Update docs
This is pretty much David's job. Especially the web page on his own
page. We have to avoid that people download old python-ldap versions
and report errors afterwards.

> so far, all that the package has is whats in Lib and the _ldapmodule.

I'm still not confident regarding the naming. IMHO the C-module
should still be called ldapmodule.so and fog's stuff should be
called ldaplib or whatever to be able to distribute both modules
separately without having to mess with different ldap.py. Different
ldap.py will cause nothing but troubles and boring FAQs by users.

And I know that there's "from _ldap import *" in ldap.py but this
does not import _ldap.__version__ and using "from module import *"
is bad behaviour anyway.

3. Fog's schema stuff
I had a short look into the schema stuff and after installing
OpenLDAP 2.0beta I learned much more about schema definitions etc.
It's much more complicated as I expected and current schema support
in ldaplib is far from being close to it (hate to say this). E.g.
you have to implement some kind of OID registry and reference all
objects with numerical OIDs.

For exercise purpose I started to write my own schema modules but
got stuck by complexity. Supporting ALL features is pretty hard. I'm
still learning and thinking. The question is if it's easier going to
OpenLDAP 2.0 API with the C-module and get schema stuff from
there...

Ciao, Michael.

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

Michael Ströder wrote:
> 
> 1. Testing:
> I tested the version of Johannes and it seems to work. I tested all
> operations (search, modify, add, modrdn, delete). Hmm, I'm thinking
> about writing a Python script which implements the BLITS test suite
> on a defined data set. This is a pretty boring job but would ease
> testing in the future.

Please also test error conditions/exceptions. It would be nasty
if a missing INCREF/surplus DECREF would make it dump core on
error conditions.

> Can anybody else say something about how stable the current version
> is?

I just sent some minor corrections to David.

> I'm still not confident regarding the naming. IMHO the C-module
> should still be called ldapmodule.so and fog's stuff should be
> called ldaplib or whatever to be able to distribute both modules
> separately without having to mess with different ldap.py. Different
> ldap.py will cause nothing but troubles and boring FAQs by users.

IMHO _ldapmodule.so + ldap.py is more flexible because it makes
it easier to add stuff to "the ldap module" in python.
ldapmodule.so requires enhancements to be implemented in C.

But Michael's right: You *MUST* include a warning about deleting
the old ldapmodule.so (or ldap.dll) in the INSTALL/README
document. It may even be a good idea to add a micro-FAQ to the
distribution.

> And I know that there's "from _ldap import *" in ldap.py but this
> does not import _ldap.__version__ and using "from module import *"
> is bad behaviour anyway.

"from module import *" is bad in user code because it a) makes it
diffcult to see which symbol was imported from where, and b)
makes namespace collisions more likely.
But it is IMHO OK (and a common idiom) for C-wrapper/interface
modules. The added flexibility for future enhancements is
invaluable.

Johannes

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

Johannes Stezenbach wrote:
> 
> IMHO _ldapmodule.so + ldap.py is more flexible because it makes
> it easier to add stuff to "the ldap module" in python.
> ldapmodule.so requires enhancements to be implemented in C.

But different versions of ldap.py will be necessary when
distributing C ldap-module and ldaplib separately. It's ok if we
rename Fog's stuff to ldaplib and keep ldap.py (small wrapper
module) and _ldapmodule.so.

And due to start-up latency when doing "import ldap" with lots of
stuff imported I want to keep both separated.

But what about the problem that _ldap.__version__ is not correctly
imported by the wrapper module ldap.py with "from _ldap import *"?

Ciao, Michael.

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

Michael Ströder wrote:
> 
> But different versions of ldap.py will be necessary when
> distributing C ldap-module and ldaplib separately.

Python has a mechanism for handling optional modules: Catch
ImportError. But this doesn't work here because of ldap.py vs.
ldap package.

> It's ok if we
> rename Fog's stuff to ldaplib and keep ldap.py (small wrapper
> module) and _ldapmodule.so.

ACK.

> And due to start-up latency when doing "import ldap" with lots of
> stuff imported I want to keep both separated.

ACK.

> But what about the problem that _ldap.__version__ is not correctly
> imported by the wrapper module ldap.py with "from _ldap import *"?

Add "from _ldap import __version__".
Note that Python is smart enough to load _ldap only once, so this
second import is fast.

Johannes

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

Johannes Stezenbach wrote:
> 
> Please also test error conditions/exceptions. It would be nasty
> if a missing INCREF/surplus DECREF would make it dump core on
> error conditions.

When using web2ldap a lot of exceptions are caught. Up to now it
looks stable. Yeah, this is not 100% sure.

Anyway a BLITS test trys to address all cases. 
See: http://www.opennc.org/directory/mats/blits24/index.htm

Ciao, Michael.

Re: 1.10alpha 'release'

[David L. <dav...@cs...>]

On Mon, 14 Aug 2000, Johannes Stezenbach typed thusly:

> Michael Ströder wrote:
> But Michael's right: You *MUST* include a warning about deleting
> the old ldapmodule.so (or ldap.dll) in the INSTALL/README
> document. It may even be a good idea to add a micro-FAQ to the
> distribution.

Perhaps the configure script could detect this and emit a warning?

	import ldap; if string.find(ldap.__file__, "ldapmodule") != -1: ...

> > And I know that there's "from _ldap import *" in ldap.py but this
> > does not import _ldap.__version__ and using "from module import *"
> > is bad behaviour anyway.

just for you, michael i've gotten ldap.py to import __version__ :)

d
-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

David Leonard wrote:
> 
> On Mon, 14 Aug 2000, Johannes Stezenbach typed thusly:
> 
> > Michael Ströder wrote:
> > But Michael's right: You *MUST* include a warning about deleting
> > the old ldapmodule.so (or ldap.dll) in the INSTALL/README
> > document. It may even be a good idea to add a micro-FAQ to the
> > distribution.
> 
> Perhaps the configure script could detect this and emit a warning?

Do you think people will ever percept it? Well, let's try.

>  import ldap; if string.find(ldap.__file__, "ldapmodule") != -1: ...
> 
> > > And I know that there's "from _ldap import *" in ldap.py but this
> > > does not import _ldap.__version__ and using "from module import *"
> > > is bad behaviour anyway.
> 
> just for you, michael i've gotten ldap.py to import __version__ :)

I did add a "from _ldap import __version__" myself in ldap.py before
but what about __symbols__ added in the future? We need robust and
consistent behaviour for all future modifications.

Ciao, Michael.

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

Michael Ströder wrote:
> 
> I did add a "from _ldap import __version__" myself in ldap.py before
> but what about __symbols__ added in the future? We need robust and
> consistent behaviour for all future modifications.

Use Guido's time machine?

But seriously, ldap.py and _ldapmodule.so must match, but that
should be no problem. Don't be too perfectionistic, Michael.

Johannes

Re: 1.10alpha 'release'

[Michael <mi...@st...>]

Johannes Stezenbach wrote:
> 
> Don't be too perfectionistic, Michael.

Yeah, yeah. But I take it as a compliment to hear that from you...

Ciao, Michael.

Re: 1.10alpha 'release'

[Johannes S. <ya...@gm...>]

David Leonard wrote:
> 
> if you have CVS access, please check out the new Build directory. 

Sorry, I didn't look at Build, but compilation from the top level
directory is broken:

$ ~/devel/ldapmodule/python-ldap-1.10a > make
cd Modules && make srcdir=./Modules VPATH=./Modules
make[1]: Entering directory
`/home/joe/devel/ldapmodule/python-ldap-1.10a/Modules'
make[1]: *** No rule to make target `Modules/LDAPObject.c',
needed by `LDAPObject.o'.  Stop.


Johannes

Re: 1.10alpha 'release'

[David L. <dav...@cs...>]

On Mon, 14 Aug 2000, Johannes Stezenbach typed thusly:

> David Leonard wrote:
> > 
> > if you have CVS access, please check out the new Build directory. 
> 
> Sorry, I didn't look at Build, but compilation from the top level
> directory is broken:
> 
> $ ~/devel/ldapmodule/python-ldap-1.10a > make
> cd Modules && make srcdir=./Modules VPATH=./Modules
> make[1]: Entering directory
> `/home/joe/devel/ldapmodule/python-ldap-1.10a/Modules'
> make[1]: *** No rule to make target `Modules/LDAPObject.c',
> needed by `LDAPObject.o'.  Stop.

oops, yes that shouldn't be ./Modules but `pwd`/Modules
will fix

-- 
David Leonard                           Dav...@cs...
Dept of Comp. Sci. and Elec. Engg   _   Room:78-640  Ph:+61 7 336 51187
The University of Queensland       |+|  http://www.csee.uq.edu.au/~leonard/
QLD 4072  AUSTRALIA               ~` '~ E2A24DC6446E5779D7AFC41AA04E6401

Curses! - Mojo Jojo

Re: 1.10alpha 'release'

[<fo...@mi...>]

Scavenging the mail folder uncovered David Leonard's letter:
> 
> so far, all that the package has is whats in Lib and the _ldapmodule.
> fog, or whoever, if you want the rest to be installed sensibly, please
> link it into the root Makefile.in.

just returned from holydays and slowly crawling through 4000 emails...
i will update _ldapmodule and move the stable stuff in the right place
asap.

ciao,
federico

-- 
Federico Di Gregorio
MIXAD LIVE System Programmer                           fo...@mi...
Debian GNU/Linux Developer & Italian Press Contact        fo...@de...
                           Don't dream it. Be it. -- Dr. Frank'n'further