On 18 Sep, 2008, at 10:20, Sebastian Hilbert wrote:
On Donnerstag 18 September 2008, Jeffrey Harris wrote:
...
To make it easier for casual developers to try things out, could we
make wx and PyICU eggs and put them on PyPI, so the whole application
is just an easy_install away? It looks like Robin has worked on
making a wx egg...
I have used the stock wxpython on openSUSE just fine. Same for pyicu
which I
packaged as rpm to be standalone. if could get around that pylucene
hell in
time I think chandler could fully work off stock libraries of
distributions.
With GNUmed we are in the same situation. Ship our own libraries for
wx,
python, pypgsql and many more.
If you opt to make it run on the distribution's stock packages it
will see a
larger userbase. Potential users are potential developers.
I agree :D. For the old codebase, it turns out that OSAF has a number
of additions/bugfixes to stock wxPython, and so Chandler won't run
against stock wxPython-2.8.8.1, for example. (It'll complain about
missing classes/methods when it tries to load the UI). Many of those
changes would be pretty useful to stock wxPython, so it would be good
to find a way to get them back to the mother ship ... I might look
into that at some point.
I haven't tested any of the demo code we did in the architecture pilot
project, but hopefully we won't have a need for anything other than
stock wxPython.
On a related note, I tried to create a wxPython binary egg on my Mac
(just to see how that would go). It turns out that once you've done a
build of the wx libraries (*), you can create a working egg by running
"python setup.py bdist_egg" inside the wxPython directory. I haven't
ever used setuptools's bdist_rpm or bdist_deb (?) commands, but maybe
those would work here, too.
--Grant
(*) not an entirely trivial task, viz:
http://wxpython.org/BUILD.html
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
