[Chandler-dev] Network installer/launcher for Leopard

Heikki Toivonen heikki at osafoundation.org
Thu Oct 11 13:23:44 PDT 2007


Andi Vajda wrote:
> 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 believe you mentioned icu 3.6 is on Leopard, as it is on Ubuntu Gutsy
Gibbon. OpenSSL is on both of these, but I've always had a hard time
getting M2Crypto to work correctly with system python and openssl on
Mac. Leopard has the right python, as does Gutsy (barring some of our
bug fixes that may be needed, which would render this moot).

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

No. Because PyLucene requires Java, we need BOTH PyLucene and Java. If
PyLucene was a pure python module we would of course still need PyLucene
but we would not need Java.

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

I didn't think Ubuntu came with Java installed by default.

>> 2. Our build would be simpler
> 
> Our build just got lots simpler by using openjdk instead of gcj.

Yes, but it could be even simpler.

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

Well, it was true before. Time will tell how we'll fare with the new
PyLucene.

> 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

Right - if there was a good enough native (Python or C) version of
Lucene I am sure we'd use it. But since there does not seem to be, we
are using the Java version. I don't think you would have created
PyLucene otherwise.

-- 
  Heikki Toivonen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20071011/8347c498/signature.pgp


More information about the chandler-dev mailing list