[XML-SIG] Availability of libxml2 and libxslt Python bindings

[M.-A. Lemburg]

Daniel Veillard wrote:
> 
> On Fri, Feb 22, 2002 at 11:43:26AM +0100, M.-A. Lemburg wrote:
> > Daniel Veillard wrote:
> > > > Seriously, I think that Fred's second proposal (combining
> > > > the Python wrapper modules, rather than the libs) solves
> > > > this best. And it should work on all platforms and with all
> > > > Python versions.
> > >
> > >   Except it seems to break my existing packaging model. Though
> > > not cast in stone I really would not like to change the RPM mapping
> > > too much. But I'm not sure I have looked at all the facet of Fred's
> > > proposal and how to actually build the stuff that way, so I will
> > > still try to get it working.
> >
> > Ideal would be if you'd factor out the Python bindings completely.
> > Then you'd have three packages libxml2, libxslt and python-libxml.
> 
>   Well this does not match my setup and existing packaging:
>      - the CVS trees, libxslt and libxml2 are in separate areas, each
>        with a python dedicated subtree
>      - the python binding testing are part of my regression tests
>        I also use the python binding to make some regression tests
>        of the libxml2 conformance, so decoupling those would IMHO
>        be a step back.
>      - the release schedules of libxml2 and libxslt are not tied,
>        though I usually roll them simultaneously it's not a rule.
>      - it should be possible to install the libxml2 python bindings
>        without installing the libxslt package, I dislike the idea of
>        putting a requirement in that direction.

I don't think you have much of a choice :-/

Note that the conformance tests could be part of the Python
binding package (users will need Python anyway in order to
run them, so you already have an extra requirement). Also,
I don't think libxml2 would have much of a problem with
having to install libxslt too. And finally, you can have 
setup.py disable the xslt support at compilation time (e.g. 
if the lib is not found) by e.g. not defining a HAVE_LIBXSLT 
symbol or simply not including the necessary .c files.

> > The advantage of this approach is that you can then use setup.py
> > to build the Python binding and also combine the two bindings
> > into one (shouldn't be too hard, since you are generating
> > the wrappers anyway, I figure).
> 
>   95% of them are generated, yes, based on API description files
> themselves generated in the libxml2/libxslt build.
> 
> > >   Microsoft packaging is anyway a domain I can't touch, I really don't
> > > have such a box and don't intend to in the foreseable future, though I
> > > usually take portability patches gracefully !
> >
> > With distutils you get this for free !
> 
>   How does distutils tell me that the libxml2/libxslt libraries where
> compiled with Cygwin versus MSC on the Windows platform ? The linking
> conventions seems to require that information and going through the doc
> of distutils I could not find anything about it.

There is no way: both use .dll as extension. However, the overall
directory setup for cygwin is different from that of MS VC and
the cygwin support in distutils will automatically use the
Unix like paths while MS VC uses its own environment.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                   http://www.egenix.com/files/python/