[Chandler-dev] Network installer/launcher for Leopard
vajda at osafoundation.org
Thu Oct 11 12:23:33 PDT 2007
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
>> 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
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
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
> 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 . Some of the reasoning in there is obsolete now of
course, Sun Java being GPL'ed is makes a big difference.
More information about the chandler-dev