On Thu, 11 Oct 2007, Heikki Toivonen wrote:
On Thu, 11 Oct 2007, Heikki Toivonen wrote:
I am not sure I follow you. Exactly because Leopard does not have
package system I proposed the easy_install model. On Ubuntu we should
NOT do easy_install, because this should be covered by the package
system (unless easy_install somehow invoked the package manager on
Ubuntu). Yes, there really are python-m2crypto, python-thisandthat
packages.
easy_install doesn't cover any of the large systems that could have an
impact on download size. Sure, we can use easy_install for all the
python packages that are present on some systems already, that would be
an improvement over our current distribution system. I thought you were
concerned about download size, though.
I guess you mean wxPython, and I agree it seems unlikely we'll be able
to rely on stock wxPython any time soon. But it seems to me we could
possibly get all other external python packages with easy_install. Still
a win.
No, I didn't even think of wxPython. I'm talking about the db, icu, openssl,
openjdk and python system in external. These are prime candidates for being
removed completely (as some are already on some systems) in a systematic,
apt-get-based way on Linux.
I don't agree that adding more dependencies to Java would be a good
thing. While PyLucene are JCC are cool, I would be much happier if we
didn't need to do it.
And why is that ?
1. If PyLucene did not have a Java-dependency, we would have a smaller
download.
That's true about any system. If Chandler didn't have a dependency on wx,
we'd have a smaller download too. Since we are shipping openjdk, by leveraging
it more, our download could become smaller. This is not something that can be
said about any other system we ship or depend on. The Java Runtime is a very
rich set of functionality. Leveraging it more does make sense.
On top of that, the Java Runtime, apart from Windows, is bound to be installed
everywhere with openjdk being the default on Linux since it's the open source
solution with the most promise.
2. Our build would be simpler
Our build just got lots simpler by using openjdk instead of gcj.
3. We would not have the complicated bugs arising from using java from
python
That's just FUD. Since switching away from gcj the bugs we might get in the
PyLucene area are not any more complicated than any other bugs we get
elsewhere.
In an ideal world Lucene would have been written with Python instead of
Java ;) (I know of the lagging ports, but as long as they lag too much
they don't seem to be an option.)
Lucene has been written in Python before. That project is called Lupy.
There also is a C++ port of Lucene called CLucene.
Why I didn't choose them for PyLucene is explained in the paper and PyCON talk
I gave a few years ago [1]. Some of the reasoning in there is obsolete now of
course, Sun Java being GPL'ed is makes a big difference.
[1] http://svn.osafoundation.org/pylucene/trunk/gcj/README
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
