Re: TLS context

[Joe L. <jl...@op...>]

ok.. answers below.

On 1/1/02 6:59 PM, "Michael Str=F6der" <mi...@st...> wrote:

> Joe Little wrote:
>>=20
>> first, another error. It looks like Lib/ldap.py is not found and a warni=
ng
>> is thrown.
>=20
> Module ldap was turned in a module package. See Lib/ldap/.
>=20
>> The generated files are handled differently by setup.py, and I
>> get a different file list. Also, a noticed a version string of
>> python-ldap-2.0.0pre1.. should I use this instead of naming it
>> "python-ldap-cvs-pythonv"
>=20
> Use a timestamp until a (pre-)release is done.
>=20
>> Here is the file list (/usr/share/doc excepted):
>>=20
>> /usr/lib/python2.1/site-packages ....
>>=20
>> _ldap.so
>> ldapurl.py
>> ldif.py
>> ldap/__init__.py
>> ldap/async.py
>> ldap/functions.py
>> ldap/ldapobject.py
>> ldap/modlist.py
>=20
> Nothing wrong with that.
>=20
>> There used to be an ldap.pth generated
>=20
> Pre-DistUtils days, was never available on Win32 anyway.
>=20
>> and other such, and it definitely include an ldap.py before.
>=20
> See ldap/__init__.py.
>=20
>> It also does not pre-compile any .py file.
>=20
> Can I pass DistUtils an option to enable byte-compiling before
> packaging?
>=20

Can't seem to find any

>> This is all changed behaviour so to speak with distutils.
>=20
> Was byte-compiling enabled in your RPM before? How?

I did a "make install" into a $DESTDIR (build root) --- make install did
everything correctly in the GNU configure days. setup.py is a bit too smart
:)

>=20
>> I cannot perform a
>> "install" since it will only generate onto the real directories and not =
an
>> alternative build root.
>=20
> What's wrong with using python setup.py bdist_rpm ? BTW: It contains
> byte-compiled *.pyc files in my case (tested right now).
>=20

It fails for me since it finds python is 1.5 (which doesn't include
distutils). Even changing the env to /usr/bin/python2 causes things to
progress and then die out later when it goes into "Python-LDAP-2.0.0pre1"
and runs setup.py again and can't import distutils (its running python1.5
again). There should be a way to handle this without env variables, since I
want to be as deterministic as possible. Second, it looks like the current
cvs snapshots enforce a 2.0.0pre1 version string. I'd need to diff away fro=
m
that but then I couldn't use bdist_rpm (you can't use it within another
RPM... :) )

>> Checking a real install, the only thing lacking is
>> the precompile of .py files, and I believe that is not necessary.
>=20
> When installing from source distribution (packaged with python
> setup.py sdist) this will do the trick:
> $ python setup.py install -O1
> $ python setup.py install -O2

what do -01 and -02 do.. or is that O1 O2 (letter 'O')? Again, this sounds
like it invokes actions on its discovered install dirs (/usr/lib instead of
/var/tmp/%var/usr/lib). Please tell me I'm wrong :)

>=20
> You could also write a small post-install script using
> compileall.py.
>=20
> Ciao, Michael.