python-ldap-dev — discussion among developers

Re: Experiments with pyasn1 and preread control

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

Andreas Hasenack wrote:
> 
> Does web2ldap have any special handling of the back-config entries?

Not up to now. But using the LDIF and HTML templates pre-configured for
cn=config name space is quite handy. You can contact me off-list if you
need further information on that.

You might find some therein:

  http://www.openldap.org/conf/odd-tuebingen-2006/Michael.pdf

The templates are available in the normal source distribution.

> I find that using a regular ldap client to handle these entries is 
> cumbersome (didn't try web2ldap: only lyma and gq so far).

In web2ldap the DN handling after add/modify is somewhat strange if the
DN is changed by X-ORDERED handling. I presented this at ODD 2006. Kurt
et al suggested to use post-read control.

Ciao, Michael.

Re: Experiments with pyasn1 and preread control

[Andreas H. <aha...@te...>]

On Thu, Jul 19, 2007 at 05:03:12PM +0200, Michael Ströder wrote:
> Andreas Hasenack wrote:
> > On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Ströder wrote:
> >> Hello Andreas,
> >>
> >> I've added your demo script to python-ldap's CVS as
> >> Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the
> >> decodeControlValue() method with pyasn1.
> > 
> > I think that would be more difficult, there are lots of classes that
> > would need to be created, I guess almost the entire LDAP specification
> > :)
> 
> Hmm...do you really think so?

That was my impression when I first tried it. Since the control result
is exactly like the ldap search result value, it means it can hold a lot
of things.

> > I'll try something with openldap's internal functions, but last time I
> > hit a rock because I needed the connection object to do that, and it
> > wasn't available.
> 
> I'd be interested to implement support for the post-read control in
> web2ldap because if you add/modify entries to OpenLDAP's back-config the
> DNs may be modified (due to X-ORDERED).

Does web2ldap have any special handling of the back-config entries? I
find that using a regular ldap client to handle these entries is
cumbersome (didn't try web2ldap: only lyma and gq so far).

Re: unicode value

[Alain S. <asp...@gm...>]

Hi

First I'm not upset by anything.

You are responsible to maintain the package in an healthy state.
This also your responsibility to add or remove some features and then
to maintain them.
Thanks for doing that.

As you have suggested, I made a class wrapper that keep  both code as
independent as possible, and I'm happy with that.

Anyway I'have some comment about your answerer ...

On 7/19/07, Michael Str=F6der <mi...@st...> wrote:
> Alain,
>
> Alain Spineux wrote:
> >
> > When investigating about python and unicode, I read somewhere (in a PEP
> > I thing) that python functions should accept and manage unicode string
> > as well as normal string.
>
> Without knowing the PEP (reference?) I guess this affects functions
> which takes a string as an argument and process it directly returning a
> result. In context of python-ldap this would be directly applicable to
> the functions in modules ldap.dn and ldap.filter.

Unicode string in python are made in a way that let the developer use them
in a complete transparent way. If the libraries are respecting this
principle too,
the developer can exchange data from different sources (user input,
SQL, ldap ...)
without never making any conversion.

The problem is strings are also used for binary storage and LDAP don't
make difference
between both usage (no charset and unicode types like in SQL), only
the developer know
and can make the conversion.

>
> The basic problem here is that for the sake of backward-compability to
> LDAPv2 the charset has to be passed around either. That's what I'm doing
> in web2ldap.
>
> > Of course if these strings could contains user
> > readable characters.
>
> Let's call that "textual strings".
>
> > Anyway I see 2 solutions
> >
> > 1. Let result() return non unicode strings. _HERE_ The user know all
> > returned
> > strings are normal strings utf-8 encoded and he can do the encoding
> > himself. A helper function doing the job for the result structure
> > should be welcome.
> >
> > 2. Do the conversion regarding the info provided in the query, as my
> > source sample does.
> >
> > I answer now some of your previous comment:
> >
> >> > In this case maybe is it possible to use [ '*', u'givenName', u'sn' =
]
> >> > to convert only 'givenName' and 'sn'
> >
> >> But then you will not gain much! Still the application has to know whi=
ch
> >> attributes have to be converted. =3D> It's not worth hiding the conver=
sion
> >> within python-ldap.
> >
> > I don't really hide the conversion, because the user has to request it =
using
> > unicode field name.
>
> I don't like this approach. The type of the attribute names is causing a
> type conversion side-effect. I don't consider this to be good design and
> I guess most Python developers would not expect something like this.
> Think about an application accidently passing in Unicode strings but is
> not really prepared to get the Unicode/string mix.

Today passing unicode argument to ldap functions raise an exception, then
no accidents is possible :-)
On the other side, with unicode support, things could accidentally
work as expected.
 But this is only speculation about witch inconvenient is the worst.

>
> > Do you really consider to add the schema processing for unicode
> > integration in the future?
>
> Nope. It's up to the application programmer, especially based on whether
> LDAPv2 support is still needed for a particular application or not. I
> consider python-ldap to be rather a low-level API.
>
> > Keep in mind, none of my code break compatibility with existing applica=
tion.
>
> Generally I don't want to discourage people to work on something. But
> sorry, I won't add your code to python-ldap's Lib/. I hope you're not
> upset. My proposal would be to add it under Demo/ so you're work can be
> considered to be used by others. Or you can put it on your own web page
> (for further development) and I'll put a link to it on
> http://python-ldap.sourceforge.net/docs.shtml.

I have no website today :-(
Please use the last version in attachment.

Regards

>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Experiments with pyasn1 and preread control

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

Andreas Hasenack wrote:
> On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Str=F6der wrote:
>> Hello Andreas,
>>
>> I've added your demo script to python-ldap's CVS as
>> Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement t=
he
>> decodeControlValue() method with pyasn1.
>=20
> I think that would be more difficult, there are lots of classes that
> would need to be created, I guess almost the entire LDAP specification
> :)

Hmm...do you really think so?

> I'll try something with openldap's internal functions, but last time I
> hit a rock because I needed the connection object to do that, and it
> wasn't available.

I'd be interested to implement support for the post-read control in
web2ldap because if you add/modify entries to OpenLDAP's back-config the
DNs may be modified (due to X-ORDERED).

Ciao, Michael.

Re: Experiments with pyasn1 and preread control

[Andreas H. <aha...@te...>]

On Thu, Jul 19, 2007 at 01:21:07PM +0200, Michael Ströder wrote:
> Hello Andreas,
> 
> I've added your demo script to python-ldap's CVS as
> Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the
> decodeControlValue() method with pyasn1.

I think that would be more difficult, there are lots of classes that
would need to be created, I guess almost the entire LDAP specification
:)

I'll try something with openldap's internal functions, but last time I
hit a rock because I needed the connection object to do that, and it
wasn't available.

Re: unicode value

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

Alain,

Alain Spineux wrote:
> 
> When investigating about python and unicode, I read somewhere (in a PEP
> I thing) that python functions should accept and manage unicode string
> as well as normal string.

Without knowing the PEP (reference?) I guess this affects functions
which takes a string as an argument and process it directly returning a
result. In context of python-ldap this would be directly applicable to
the functions in modules ldap.dn and ldap.filter.

The basic problem here is that for the sake of backward-compability to
LDAPv2 the charset has to be passed around either. That's what I'm doing
in web2ldap.

> Of course if these strings could contains user
> readable characters.

Let's call that "textual strings".

> Anyway I see 2 solutions
> 
> 1. Let result() return non unicode strings. _HERE_ The user know all
> returned
> strings are normal strings utf-8 encoded and he can do the encoding
> himself. A helper function doing the job for the result structure
> should be welcome.
> 
> 2. Do the conversion regarding the info provided in the query, as my
> source sample does.
> 
> I answer now some of your previous comment:
> 
>> > In this case maybe is it possible to use [ '*', u'givenName', u'sn' ]
>> > to convert only 'givenName' and 'sn'
> 
>> But then you will not gain much! Still the application has to know which
>> attributes have to be converted. => It's not worth hiding the conversion
>> within python-ldap.
> 
> I don't really hide the conversion, because the user has to request it using
> unicode field name.

I don't like this approach. The type of the attribute names is causing a
type conversion side-effect. I don't consider this to be good design and
I guess most Python developers would not expect something like this.
Think about an application accidently passing in Unicode strings but is
not really prepared to get the Unicode/string mix.

> Do you really consider to add the schema processing for unicode
> integration in the future?

Nope. It's up to the application programmer, especially based on whether
LDAPv2 support is still needed for a particular application or not. I
consider python-ldap to be rather a low-level API.

> Keep in mind, none of my code break compatibility with existing application.

Generally I don't want to discourage people to work on something. But
sorry, I won't add your code to python-ldap's Lib/. I hope you're not
upset. My proposal would be to add it under Demo/ so you're work can be
considered to be used by others. Or you can put it on your own web page
(for further development) and I'll put a link to it on
http://python-ldap.sourceforge.net/docs.shtml.

Ciao, Michael.

Re: Experiments with pyasn1 and preread control

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

Hello Andreas,

I've added your demo script to python-ldap's CVS as
Demo/pyasn1/prereadcontrol.py. I'd appreciate if you could implement the
decodeControlValue() method with pyasn1.

Ciao, Michael.

Andreas Hasenack wrote:
> I have been having fun with controls. Today I tried to use the Pre-Read
> control together with the modify+increment extension, so that
> modify+increment becomes actually useful.
> 
> I first added the encoding part to the ldap.so module, but later got a
> response from the pyasn1 mailing list and tried again in pure python.
> The result is attached. It's not complete yet, just a test.
> 
> The script uses mod_increment to increment uidNumber and gidNumber by
> one. Attached to the modify operation is the preread control, so the
> response includes the value prior to the modification.
> 
> Here is the output of two consecutive runs. Both attributes started at
> 1000 in LDAP:
> 
> $ ./preread-asn1.py
> res: (103, [], 2, [PreReadControl(1.3.6.1.1.13.1,1.3.6.1.1.13.1,'0M\x04\x1fcn=unixIdPool,dc=example,dc=com0*0\x13\x04\tgidNumber1\x06\x04\x0410000\x13\x04\tuidNumber1\x06\x04\x041000')])
> $ ./preread-asn1.py
> res: (103, [], 2, [PreReadControl(1.3.6.1.1.13.1,1.3.6.1.1.13.1,'0M\x04\x1fcn=unixIdPool,dc=example,dc=com0*0\x13\x04\tgidNumber1\x06\x04\x0410010\x13\x04\tuidNumber1\x06\x04\x041001')])
> 
> First one returns "1000", and the second one "1001" for both attributes.
> Now it's at 1002.
> 
> The decoding part will probably be more difficult... As the control
> response is a SearchResultEntry which is a bit more complex to decode.

Re: Preparing release 2.3.1

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

Ryan Lovett wrote:
> On Wed, Jul 18, 2007 at 02:00:14PM +0200, Alain Spineux wrote:
>> Don't  forget your package is already included in some distribution
>> and then widely available.
> 
> Given that python-ldap is packaged by almost everyone, (excluding
> Microsoft, Apple, and Sun) what is there to gain with this binary
> distribution effort?

One benefit would be to provide a more recent version of python-ldap
than the distributor. But IMO this won't really work.

> Would anyone using Debian/Ubuntu, Red Hat/Fedora,
> SuSE, Mandriva, etc. require this project to distribute .egg files?

I don't think so. They have their own packaging system.

> I have no experience with using .eggs.

Nor have I.

Ciao, Michael.

Re: Preparing release 2.3.1

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

Alain Spineux wrote:
> Don't  forget your package is already included in some distribution
> and then widely available.

Well, the coordination with distribution maintainers is somewhat
difficult anyway. But the distributor has to take care of dependencies.

> The best effort solution is to publish the version you can and all
> spontaneous contributions.

Example: I'm using openSUSE 10.2. But if I provide a build for that
system it doesn't help anybody since I always have recent OpenLDAP libs
under /opt/openldap-2.3. Or I might temporarily build against the
heimdal libs instead of MIT libs shipped with openSUSE.
=> Personally I won't provide any builds.

Ciao, Michael.

Re: Preparing release 2.3.1

[Timur I. <Tim...@oi...>]

Ryan Lovett wrote:
> On Wed, Jul 18, 2007 at 02:00:14PM +0200, Alain Spineux wrote:
>> Don't  forget your package is already included in some distribution
>> and then widely available.
> 
> Given that python-ldap is packaged by almost everyone, (excluding
> Microsoft, Apple, and Sun) what is there to gain with this binary
> distribution effort? Would anyone using Debian/Ubuntu, Red Hat/Fedora,
> SuSE, Mandriva, etc. require this project to distribute .egg files? I ask
> out of genuine curiosity, not to dissuade whoever is interested from
> pursuing this. I have no experience with using .eggs.

Good question.

The problem is that setuptools won't detect python-ldap installed from distro 
(it's not recorded in .pth files) and this prevents developers from declaring 
their projects' requirements in setup.py. Providing the URL to the python-ldap 
download page doesn't help because at the moment the source code has to be 
configured manually before build.

I personally would prefer to build an .egg from source because python-ldap is 
packaged differently across the distros. For example in Debian it is linked 
against gnutls rather than openssl.

So, this is mostly a setuptools'/distribution problem.

-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi...
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com

Re: Preparing release 2.3.1

[Ryan L. <ry...@st...>]

On Wed, Jul 18, 2007 at 02:00:14PM +0200, Alain Spineux wrote:
> Don't  forget your package is already included in some distribution
> and then widely available.

Given that python-ldap is packaged by almost everyone, (excluding
Microsoft, Apple, and Sun) what is there to gain with this binary
distribution effort? Would anyone using Debian/Ubuntu, Red Hat/Fedora,
SuSE, Mandriva, etc. require this project to distribute .egg files? I ask
out of genuine curiosity, not to dissuade whoever is interested from
pursuing this. I have no experience with using .eggs.

Ryan

Re: Preparing release 2.3.1

[Alain S. <asp...@gm...>]

Don't  forget your package is already included in some distribution
and then widely available.

Personally I'm happy to have eggs functionality to deploy the same egg
on multiple identical machine with custom configuration.

The best effort solution is to publish the version you can and all
spontaneous contributions.

Regards


On 7/18/07, Michael Str=F6der <mi...@st...> wrote:
> David Leonard wrote:
> >  Perhaps there might be some interest in people running buildbot slaves=
?
> > (http://buildbot.net/)
> > Michael, you could run a trusted buildmaster, and helpers would run
> > buildslaves that connect to your master.
>
> Frankly I don't have currently the time for diving into it.
>
> We have so many dependencies, each deployer of python-ldap could have
> different needs:
> Python
> OpenLDAP
> Cyrus-SASL
> Kerberos (MIT/heimdal)
> OpenSSL
>
> I'm rather reluctant to open that can of worms...
>
> Ciao, Michael.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Preparing release 2.3.1

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

David Leonard wrote:
>  Perhaps there might be some interest in people running buildbot slaves?
> (http://buildbot.net/)
> Michael, you could run a trusted buildmaster, and helpers would run
> buildslaves that connect to your master.

Frankly I don't have currently the time for diving into it.

We have so many dependencies, each deployer of python-ldap could have
different needs:
Python
OpenLDAP
Cyrus-SASL
Kerberos (MIT/heimdal)
OpenSSL

I'm rather reluctant to open that can of worms...

Ciao, Michael.

Re: Preparing release 2.3.1

[David L. <d...@ad...>]

Perhaps there might be some interest in people running buildbot slaves? 
(http://buildbot.net/)
Michael, you could run a trusted buildmaster, and helpers would run 
buildslaves that connect to your master.

Michael Ströder wrote:
> Torsten Kurbad wrote:
>   
>>> I'd like to release 2.3.1 soon.
>>>       
>> still one question: Do you plan to upload some .eggs to PyPI then?
>> I meanwhile successfully build eggs for i686-linux as well as Mac OS
>> X 10.4 PPC (Intel platforms should work the same way) using Py 2.3 +
>> 2.4.
>>
>> Nice to have would be an egg for the Windows platform, which I can't
>> build due to the lack of a proper Windows devel environment.
>>
>> Anyway, after 2.3.1 is released, I'd be happy to contribute the
>> mentioned .egg files - could you then upload them to PyPI? I could do
>> that, too, but it's for you to decide...
>>     
>
> Being in the role of the maintainer I'm always concerned about
> continuous support for a certain mechanism. Since .egg files are
> platform-specific the question arises:
> Who is going to provide which builds for every new release?
> On which platforms/distros?
> With which OpenLDAP/SASL/OpenSSL libs?
>
> Today especially the situation regarding Win32 builds is poor. A
> *strong* commitment of volunteers is needed...
>
> Ciao, Michael.
>
> -


-- 
David Leonard                           d...@ad...
                                        Ph:+61 404 844 850

Re[2]: Preparing release 2.3.1

[Torsten K. <pyt...@tk...>]

On Wednesday, July 18, 2007 at 08:01 Michael Str=F6der wrote:

> Being in the role of the maintainer I'm always concerned about
> continuous support for a certain mechanism.

Understandable.

> Since .egg files are
> platform-specific the question arises:
> Who is going to provide which builds for every new release?

Good question.

> On which platforms/distros?
> With which OpenLDAP/SASL/OpenSSL libs?

There are some systems that make the decision easy:
Mac OS X, e.g. comes with a set of SASL and OpenLDAP libs by default.
After getting the necessary headers from a Linux-Installation I was able
to build .eggs there with the standard system-Python (2.3.5).

On Linux, of course, the situation is much more difficult. I use Gentoo,
which is in many ways very standards compatible, but I use bleeding edge
libraries, like glibc 2.6, OpenLDAP 2.3.36 etc.
The past showed that an old distribution, like RedHat 8, combined with
some newer libraries, but with an "old" glibc provides almost 100%
compatibility of binary builds to other distros.

I think, it's a question of defining prerequisites, like: If you want to
run this from an .egg, you need at least OpenLDAP 2.3, etc.

But still, it's a complex task that should be shared among several
people.

> Today especially the situation regarding Win32 builds is poor. A
> *strong* commitment of volunteers is needed...

Yes, I understand that.
For the moment let's perhaps agree to the following:

After 2.3.1 is out, I will build .eggs on every platform and every OS at
my disposal and put them in our "private" distribution  at

http://svn.kmrc.de/distribution

If you want to, you may announce that on the Homepage and/or in the docs
then, but with a remark saying that these .eggs may be out of date.
Whenever I can spare the time, I'll build .eggs for upcoming releases.

Greetings,
Torsten
--=20
Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de

Never make anything simple and efficient when a way can be found to
make it complex and wonderful.              - Murphy's Law No. 13 -

Re: Preparing release 2.3.1

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

Torsten Kurbad wrote:
>> I'd like to release 2.3.1 soon.
> still one question: Do you plan to upload some .eggs to PyPI then?
> I meanwhile successfully build eggs for i686-linux as well as Mac OS
> X 10.4 PPC (Intel platforms should work the same way) using Py 2.3 +
> 2.4.
> 
> Nice to have would be an egg for the Windows platform, which I can't
> build due to the lack of a proper Windows devel environment.
> 
> Anyway, after 2.3.1 is released, I'd be happy to contribute the
> mentioned .egg files - could you then upload them to PyPI? I could do
> that, too, but it's for you to decide...

Being in the role of the maintainer I'm always concerned about
continuous support for a certain mechanism. Since .egg files are
platform-specific the question arises:
Who is going to provide which builds for every new release?
On which platforms/distros?
With which OpenLDAP/SASL/OpenSSL libs?

Today especially the situation regarding Win32 builds is poor. A
*strong* commitment of volunteers is needed...

Ciao, Michael.

Re: Preparing release 2.3.1

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

Alain Spineux wrote:
> I did this, and it looks to be working.

Ouch! Modules/constants.c was not comitted to CVS.
Thanks.

> Also with my unicode extension :-)

I knew you would ask for it. I will follow-up on this later...

Ciao, Michael.

Re: Preparing release 2.3.1

[Torsten K. <pyt...@tk...>]

Alain Spineux wrote:
> Hi again
>
> Could you add a note about how to build an egg at the end of INSALL file ?
> To avoid to spend 10min looking for the correct syntax in the
> setuptools documentation :-)
>   

The setup.py comes with a very neat option that could have saved you
lots of trouble and works with both distutils and setuptools. ;o)

Try:

python setup.py --help-commands

Regards,
Torsten

-- 
Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de

Ich schreibe dir einen langen Brief, weil ich keine Zeit habe,
einen kurzen zu schreiben.    -- Johann Wolfgang von Goethe --

Re: Preparing release 2.3.1

[Alain S. <asp...@gm...>]

Hi again

Could you add a note about how to build an egg at the end of INSALL file ?
To avoid to spend 10min looking for the correct syntax in the
setuptools documentation :-)

python setup.py  bdist_egg

thanks

On 7/17/07, Alain Spineux <asp...@gm...> wrote:
> I did this, and it looks to be working.
> Also with my unicode extension :-)
>
>
> diff -r -c python-ldap-2.3.1/Modules/constants.c python-ldap/Modules/cons=
tants.c
> *** python-ldap-2.3.1/Modules/constants.c       Tue Jun  5 11:56:15 2007
> --- python-ldap/Modules/constants.c     Tue Jul 17 15:26:14 2007
> ***************
> *** 263,266 ****
> --- 263,270 ----
>         PyDict_SetItemString( d, "LDAP_CONTROL_PAGE_OID", obj );
>         Py_DECREF(obj);
>
> +       obj =3D PyString_FromString(LDAP_CONTROL_VALUESRETURNFILTER);
> +       PyDict_SetItemString( d, "LDAP_CONTROL_VALUESRETURNFILTER", obj )=
;
> +       Py_DECREF(obj);
> +
>   }
>
>
>
> On 7/17/07, Alain Spineux <asp...@gm...> wrote:
> > Hi
> > I tried the CVS head and got problem
> >
> > First I got this error when building the egg
> >
> > cc: unrecognized option '-R/usr/local/openldap-2.3/lib'
> >
> > The full command is
> >
> > /kolab/bin/cc -pthread -shared
> > build/temp.linux-i686-2.4/Modules/LDAPObject.o
> > build/temp.linux-i686-2.4/Modules/ldapcontrol.o
> > build/temp.linux-i686-2.4/Modules/common.o
> > build/temp.linux-i686-2.4/Modules/constants.o
> > build/temp.linux-i686-2.4/Modules/errors.o
> > build/temp.linux-i686-2.4/Modules/functions.o
> > build/temp.linux-i686-2.4/Modules/schema.o
> > build/temp.linux-i686-2.4/Modules/ldapmodule.o
> > build/temp.linux-i686-2.4/Modules/message.o
> > build/temp.linux-i686-2.4/Modules/version.o
> > build/temp.linux-i686-2.4/Modules/options.o
> > -L/usr/local/openldap-2.3/lib -R/usr/local/openldap-2.3/lib -lldap_r
> > -llber -lsasl2 -lssl -lcrypto -o build/lib.linux-i686-2.4/_ldap.so
> >
> > I removed the references to /usr/local/openldap-2.3/ in setup.cfg and
> > got and egg, I installed
> > the egg and removed any old file from site packages
> >
> > rm -rf dsml.py   dsml.pyo    ldapurl.pyc  ldif.py   ldif.pyo dsml.pyc
> > ldapurl.py  ldapurl.pyo  ldif.pyc ldap/
> >
> > I got the fologing error when starting my project:
> >
> > Traceback (most recent call last):
> >   File "./start-emailgency.py", line 53, in ?
> >     from emailgency.controllers import Root
> >   File "/s0/asx/src/emailgency/trunk/emailgency/controllers.py", line 8=
, in ?
> >     import main_ctrl, pas_sub_ctrl, addr_ctrl, common_ctrl
> >   File "/s0/asx/src/emailgency/trunk/emailgency/main_ctrl.py", line 12,=
 in ?
> >     from emailgency import json, eg_dns, eg_mail, rrdtoolx, egsyslib, e=
g_config
> >   File "/s0/asx/src/emailgency/trunk/emailgency/egsyslib.py", line 8, i=
n ?
> >     from eg_kolab_lib import KolabConnection
> >   File "/s0/asx/src/emailgency/trunk/emailgency/eg_kolab_lib.py", line =
4, in ?
> >     import ldap, ldap.modlist, ldapurl
> >   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i=
686.egg/ldap/__init__.py",
> > line 48, in ?
> >     from functions import open,initialize,init,get_option,set_option
> >   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i=
686.egg/ldap/functions.py",
> > line 36, in ?
> >     from ldap.ldapobject import LDAPObject
> >   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i=
686.egg/ldap/ldapobject.py",
> > line 40, in ?
> >     from ldap.controls import
> > LDAPControl,DecodeControlTuples,EncodeControlTuples
> >   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i=
686.egg/ldap/controls.py",
> > line 85, in ?
> >     class MatchedValuesControl(LDAPControl):
> >   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i=
686.egg/ldap/controls.py",
> > line 93, in MatchedValuesControl
> >     controlType =3D ldap.LDAP_CONTROL_VALUESRETURNFILTER
> > AttributeError: 'module' object has no attribute
> > 'LDAP_CONTROL_VALUESRETURNFILTER'
> >
> > any idea ?
> >
> > On 7/16/07, Michael Str=F6der <mi...@st...> wrote:
> > > HI!
> > >
> > > I'd like to release 2.3.1 soon. There are some interesting improvemen=
ts
> > > in HEAD but not yet released. Therefore testing of HEAD is needed.
> > > Thanks to the contributors!
> > >
> > > Please provide feedback ideally on the mailing list. Thanks.
> > >
> > > Ciao, Michael.
> > >
> > > Current CHANGES:
> > >
> > > Released 2.3.1 2007-07-xx
> > >
> > > Changes since 2.3.0:
> > >
> > > * Support for setuptools (building .egg, thanks to Torsten)
> > > * Support for matched values control (RFC 3876, thanks to Andreas)
> > >
> > > Lib/
> > > * Fixed ldif (see SF#1709111, thanks to Dmitry)
> > >
> > > Modules/
> > > * Added constant MOD_INCREMENT to support
> > >   modify+increment extension (see RFC 4525, thanks to Andreas)
> > >
> > > ---------------------------------------------------------------------=
----
> > > This SF.net email is sponsored by DB2 Express
> > > Download DB2 Express C - the FREE version of DB2 express and take
> > > control of your XML. No limits. Just data. Click to get it now.
> > > http://sourceforge.net/powerbar/db2/
> > > _______________________________________________
> > > Python-LDAP-dev mailing list
> > > Pyt...@li...
> > > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> > >
> >
> >
> > --
> > --
> > Alain Spineux
> > aspineux gmail com
> > May the sources be with you
> >
>
>
> --
> --
> Alain Spineux
> aspineux gmail com
> May the sources be with you
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Preparing release 2.3.1

[Alain S. <asp...@gm...>]

I did this, and it looks to be working.
Also with my unicode extension :-)


diff -r -c python-ldap-2.3.1/Modules/constants.c python-ldap/Modules/consta=
nts.c
*** python-ldap-2.3.1/Modules/constants.c       Tue Jun  5 11:56:15 2007
--- python-ldap/Modules/constants.c     Tue Jul 17 15:26:14 2007
***************
*** 263,266 ****
--- 263,270 ----
        PyDict_SetItemString( d, "LDAP_CONTROL_PAGE_OID", obj );
        Py_DECREF(obj);

+       obj =3D PyString_FromString(LDAP_CONTROL_VALUESRETURNFILTER);
+       PyDict_SetItemString( d, "LDAP_CONTROL_VALUESRETURNFILTER", obj );
+       Py_DECREF(obj);
+
  }



On 7/17/07, Alain Spineux <asp...@gm...> wrote:
> Hi
> I tried the CVS head and got problem
>
> First I got this error when building the egg
>
> cc: unrecognized option '-R/usr/local/openldap-2.3/lib'
>
> The full command is
>
> /kolab/bin/cc -pthread -shared
> build/temp.linux-i686-2.4/Modules/LDAPObject.o
> build/temp.linux-i686-2.4/Modules/ldapcontrol.o
> build/temp.linux-i686-2.4/Modules/common.o
> build/temp.linux-i686-2.4/Modules/constants.o
> build/temp.linux-i686-2.4/Modules/errors.o
> build/temp.linux-i686-2.4/Modules/functions.o
> build/temp.linux-i686-2.4/Modules/schema.o
> build/temp.linux-i686-2.4/Modules/ldapmodule.o
> build/temp.linux-i686-2.4/Modules/message.o
> build/temp.linux-i686-2.4/Modules/version.o
> build/temp.linux-i686-2.4/Modules/options.o
> -L/usr/local/openldap-2.3/lib -R/usr/local/openldap-2.3/lib -lldap_r
> -llber -lsasl2 -lssl -lcrypto -o build/lib.linux-i686-2.4/_ldap.so
>
> I removed the references to /usr/local/openldap-2.3/ in setup.cfg and
> got and egg, I installed
> the egg and removed any old file from site packages
>
> rm -rf dsml.py   dsml.pyo    ldapurl.pyc  ldif.py   ldif.pyo dsml.pyc
> ldapurl.py  ldapurl.pyo  ldif.pyc ldap/
>
> I got the fologing error when starting my project:
>
> Traceback (most recent call last):
>   File "./start-emailgency.py", line 53, in ?
>     from emailgency.controllers import Root
>   File "/s0/asx/src/emailgency/trunk/emailgency/controllers.py", line 8, =
in ?
>     import main_ctrl, pas_sub_ctrl, addr_ctrl, common_ctrl
>   File "/s0/asx/src/emailgency/trunk/emailgency/main_ctrl.py", line 12, i=
n ?
>     from emailgency import json, eg_dns, eg_mail, rrdtoolx, egsyslib, eg_=
config
>   File "/s0/asx/src/emailgency/trunk/emailgency/egsyslib.py", line 8, in =
?
>     from eg_kolab_lib import KolabConnection
>   File "/s0/asx/src/emailgency/trunk/emailgency/eg_kolab_lib.py", line 4,=
 in ?
>     import ldap, ldap.modlist, ldapurl
>   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i68=
6.egg/ldap/__init__.py",
> line 48, in ?
>     from functions import open,initialize,init,get_option,set_option
>   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i68=
6.egg/ldap/functions.py",
> line 36, in ?
>     from ldap.ldapobject import LDAPObject
>   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i68=
6.egg/ldap/ldapobject.py",
> line 40, in ?
>     from ldap.controls import
> LDAPControl,DecodeControlTuples,EncodeControlTuples
>   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i68=
6.egg/ldap/controls.py",
> line 85, in ?
>     class MatchedValuesControl(LDAPControl):
>   File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i68=
6.egg/ldap/controls.py",
> line 93, in MatchedValuesControl
>     controlType =3D ldap.LDAP_CONTROL_VALUESRETURNFILTER
> AttributeError: 'module' object has no attribute
> 'LDAP_CONTROL_VALUESRETURNFILTER'
>
> any idea ?
>
> On 7/16/07, Michael Str=F6der <mi...@st...> wrote:
> > HI!
> >
> > I'd like to release 2.3.1 soon. There are some interesting improvements
> > in HEAD but not yet released. Therefore testing of HEAD is needed.
> > Thanks to the contributors!
> >
> > Please provide feedback ideally on the mailing list. Thanks.
> >
> > Ciao, Michael.
> >
> > Current CHANGES:
> >
> > Released 2.3.1 2007-07-xx
> >
> > Changes since 2.3.0:
> >
> > * Support for setuptools (building .egg, thanks to Torsten)
> > * Support for matched values control (RFC 3876, thanks to Andreas)
> >
> > Lib/
> > * Fixed ldif (see SF#1709111, thanks to Dmitry)
> >
> > Modules/
> > * Added constant MOD_INCREMENT to support
> >   modify+increment extension (see RFC 4525, thanks to Andreas)
> >
> > -----------------------------------------------------------------------=
--
> > This SF.net email is sponsored by DB2 Express
> > Download DB2 Express C - the FREE version of DB2 express and take
> > control of your XML. No limits. Just data. Click to get it now.
> > http://sourceforge.net/powerbar/db2/
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> >
>
>
> --
> --
> Alain Spineux
> aspineux gmail com
> May the sources be with you
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Preparing release 2.3.1

[Alain S. <asp...@gm...>]

Hi
I tried the CVS head and got problem

First I got this error when building the egg

cc: unrecognized option '-R/usr/local/openldap-2.3/lib'

The full command is

/kolab/bin/cc -pthread -shared
build/temp.linux-i686-2.4/Modules/LDAPObject.o
build/temp.linux-i686-2.4/Modules/ldapcontrol.o
build/temp.linux-i686-2.4/Modules/common.o
build/temp.linux-i686-2.4/Modules/constants.o
build/temp.linux-i686-2.4/Modules/errors.o
build/temp.linux-i686-2.4/Modules/functions.o
build/temp.linux-i686-2.4/Modules/schema.o
build/temp.linux-i686-2.4/Modules/ldapmodule.o
build/temp.linux-i686-2.4/Modules/message.o
build/temp.linux-i686-2.4/Modules/version.o
build/temp.linux-i686-2.4/Modules/options.o
-L/usr/local/openldap-2.3/lib -R/usr/local/openldap-2.3/lib -lldap_r
-llber -lsasl2 -lssl -lcrypto -o build/lib.linux-i686-2.4/_ldap.so

I removed the references to /usr/local/openldap-2.3/ in setup.cfg and
got and egg, I installed
the egg and removed any old file from site packages

rm -rf dsml.py   dsml.pyo    ldapurl.pyc  ldif.py   ldif.pyo dsml.pyc
ldapurl.py  ldapurl.pyo  ldif.pyc ldap/

I got the fologing error when starting my project:

Traceback (most recent call last):
  File "./start-emailgency.py", line 53, in ?
    from emailgency.controllers import Root
  File "/s0/asx/src/emailgency/trunk/emailgency/controllers.py", line 8, in=
 ?
    import main_ctrl, pas_sub_ctrl, addr_ctrl, common_ctrl
  File "/s0/asx/src/emailgency/trunk/emailgency/main_ctrl.py", line 12, in =
?
    from emailgency import json, eg_dns, eg_mail, rrdtoolx, egsyslib, eg_co=
nfig
  File "/s0/asx/src/emailgency/trunk/emailgency/egsyslib.py", line 8, in ?
    from eg_kolab_lib import KolabConnection
  File "/s0/asx/src/emailgency/trunk/emailgency/eg_kolab_lib.py", line 4, i=
n ?
    import ldap, ldap.modlist, ldapurl
  File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.=
egg/ldap/__init__.py",
line 48, in ?
    from functions import open,initialize,init,get_option,set_option
  File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.=
egg/ldap/functions.py",
line 36, in ?
    from ldap.ldapobject import LDAPObject
  File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.=
egg/ldap/ldapobject.py",
line 40, in ?
    from ldap.controls import
LDAPControl,DecodeControlTuples,EncodeControlTuples
  File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.=
egg/ldap/controls.py",
line 85, in ?
    class MatchedValuesControl(LDAPControl):
  File "/kolab/lib/python/site-packages/python_ldap-2.3.1-py2.4-linux-i686.=
egg/ldap/controls.py",
line 93, in MatchedValuesControl
    controlType =3D ldap.LDAP_CONTROL_VALUESRETURNFILTER
AttributeError: 'module' object has no attribute
'LDAP_CONTROL_VALUESRETURNFILTER'

any idea ?

On 7/16/07, Michael Str=F6der <mi...@st...> wrote:
> HI!
>
> I'd like to release 2.3.1 soon. There are some interesting improvements
> in HEAD but not yet released. Therefore testing of HEAD is needed.
> Thanks to the contributors!
>
> Please provide feedback ideally on the mailing list. Thanks.
>
> Ciao, Michael.
>
> Current CHANGES:
>
> Released 2.3.1 2007-07-xx
>
> Changes since 2.3.0:
>
> * Support for setuptools (building .egg, thanks to Torsten)
> * Support for matched values control (RFC 3876, thanks to Andreas)
>
> Lib/
> * Fixed ldif (see SF#1709111, thanks to Dmitry)
>
> Modules/
> * Added constant MOD_INCREMENT to support
>   modify+increment extension (see RFC 4525, thanks to Andreas)
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: Preparing release 2.3.1

[Torsten K. <pyt...@tk...>]

Timur Izhbulatov wrote:
>
> According to [1] buildout supports the 'find-links' option which
> should solve your problem.

Yes, I actively use that option to support our local eggs... ;o)

So, not to get into some misunderstandings here: You'd like to keep the
_precompiled_ .eggs in sf.net , not just the source? That would be
perfectly fine with me.

Regards,
Torsten

-- 
Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de

Ich schreibe dir einen langen Brief, weil ich keine Zeit habe,
einen kurzen zu schreiben.    -- Johann Wolfgang von Goethe --

Re: Preparing release 2.3.1

[Timur I. <Tim...@oi...>]

Torsten Kurbad wrote:
> Timur Izhbulatov wrote:
>> Don't forget that the easy_install command works perfectly with
>> project download pages on sf.net. So, I don't think it is necessary to
>> upload .eggs to PyPI.
> The question for me is: Does zc.buildout support this method. To clearify: We are developing projects that are widely based on Zope3 (http://www.zope.org). The zope corporation developed a concept named buildout to install .eggs locally in a project directory, which is interesting for users who don't have permission to write into the system's site-packages. This way, also different versions of python packages may coexist peacefully, since buildouts don't know the environment of their neighbors.
> 
> I will check, if the buildout.cfg supports checking out and building eggs from sf.net, but nevertheless, building on e.g. OS X is a bit tricky, since it lacks the appropriate openldap-2.3 and sasl headers, not even to speak of Win32...

According to [1] buildout supports the 'find-links' option which should solve 
your problem. Also, I don't think it has something to do with the location of 
your python libraries. For example, I keep most of the stuff I need in 
$HOME/lib/python.

> And uploading to PyPI is as easy as:
> 
> # python setup.py register bdist_egg upload

Of course. But I think it's better to keep all eggs in one basket =)

[1] http://www.zope.org/DevHome/Buildout/egg.html

Cheers,
-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi...
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com

Re: Preparing release 2.3.1

[Torsten K. <pyt...@tk...>]

Timur Izhbulatov wrote:
> Don't forget that the easy_install command works perfectly with
> project download pages on sf.net. So, I don't think it is necessary to
> upload .eggs to PyPI.
The question for me is: Does zc.buildout support this method. To clearify: We are developing projects that are widely based on Zope3 (http://www.zope.org). The zope corporation developed a concept named buildout to install .eggs locally in a project directory, which is interesting for users who don't have permission to write into the system's site-packages. This way, also different versions of python packages may coexist peacefully, since buildouts don't know the environment of their neighbors.

I will check, if the buildout.cfg supports checking out and building eggs from sf.net, but nevertheless, building on e.g. OS X is a bit tricky, since it lacks the appropriate openldap-2.3 and sasl headers, not even to speak of Win32...

And uploading to PyPI is as easy as:

# python setup.py register bdist_egg upload

Regards,
Torsten
-- 
Fon: +49-7071-700240 | Fax: +49-7071-700241 | http://www.tk-webart.de

Ich schreibe dir einen langen Brief, weil ich keine Zeit habe,
einen kurzen zu schreiben.    -- Johann Wolfgang von Goethe --

Re: Preparing release 2.3.1

[Timur I. <Tim...@oi...>]

Torsten Kurbad wrote:
> Hi Michael,
>> I'd like to release 2.3.1 soon.
> still one question: Do you plan to upload some .eggs to PyPI then?
> I meanwhile successfully build eggs for i686-linux as well as Mac OS X 10.4 PPC (Intel platforms should work the same way) using Py 2.3 + 2.4.
> 
> Nice to have would be an egg for the Windows platform, which I can't build due to the lack of a proper Windows devel environment.
> 
> Anyway, after 2.3.1 is released, I'd be happy to contribute the mentioned .egg files - could you then upload them to PyPI?
> I could do that, too, but it's for you to decide...
> 

Hi guys,

Don't forget that the easy_install command works perfectly with project 
download pages on sf.net. So, I don't think it is necessary to upload .eggs to 
PyPI. In my opinion it would be better to keep files on sf.net and publish just 
the URL to the download page on PyPI.

Best Regards,
-- 
Timur Izhbulatov
OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia
P:+7 495 105 7245 + ext.205 F:+7 495 105 7246 E:Tim...@oi...
Building Successful Supply Chains - One Solution At A Time.
www.oilspace.com