On Mon, 24 Mar 2008, Bill Janssen wrote:
For simplicity's sake, until modern setuptools is widespread
Good luck with that... Wake me in 2015.
I'd like to keep the static case simplest and the default.
I don't like that approach, because it means that two JCC-generated
modules won't live together in the same Python.
By default, that is true. If JCC gets more users beyond PyLucene, this may
become an issue if you want to think of a 1-1 mapping between java software
packages and their python wrappings when using JCC.
On the other hand, I've started using JCC outside of PyLucene by just
wrapping the classes I needed to glue together my python code and my java
code in a more ad-hoc way, as if I was using a C compiler and linker to pull
in outside libraries. I'm not creating a new 'library', I'm just using a
bunch of libraries using jcc as the compiler/linker linking them together.
I'm not sure what the right approach is at the moment and I'm waiting for
more such uses to tell. Most people today get acquainted with JCC via
PyLucene today and I don't want to make it any harder to do builds.
Requiring the shared library is just one more point of failure.
If I understand this right, this is only about the build. A
distribution of a JCC-wrapped module can be built "shared", and
distributed, and the target machine need not have setuptools installed
to have everything work properly.
If my understanding is correct, distutils understands enough about eggs to
load a JCC-built extension without setuptools present.
Given this, I'd still think that doing things "shared" by default is a
good thing; it requires the builder to have a modern setuptools (and can
complain if they don't), which is not a difficult thing to achieve, but
avoids the problems of non-shared module distributions "poisoning" the
Python for other modules.
We're almost there already. The shared library is built via setup.py by
default provided setuptools >= 0.6c7 is present and you're on Linux, Mac or
Windows. Until the remaining bugs that make this brittle because of the
manual steps required, static is going to remain the default as I don't want
to make it any more difficult to build PyLucene or any other JCC-built
extension. Currently, these remaining steps are:
- on Linux:
. install a setuptools >= 0.6c7
- on Windows:
. install a setuptools >= 0.6c7
. manually copy the jcc.lib import library into the JCC egg directory
- on Mac OS X
. on Leopard: none
. pre-Leopard: install a setuptools >= 0.6c7
Still, I think that you're poisoning case is strong. The good thing with
using open source is that it shouldn't be unsurmontable to rebuild the
poisoning module to use --shared until modern setuptools use is widespread.
There probably is still a way to poison things on some OSs even when using
--shared. If you were to install the shared jcc lib in separate locations
and somehow managed to load it multiple times, the same problem would
occur.
Andi..
_______________________________________________
pylucene-dev mailing list
[email protected]
http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
