[Chandler-dev] Network installer/launcher for Leopard

[Andi Vajda]

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..