Future Python Gui?

Magnus Lycka lycka at carmen.se
Fri Apr 20 15:12:10 CEST 2007


Jarek Zgoda wrote:
> I am not a hacker, just a software developer, but I'd have no problems
> in either installing PyGTK on Ubuntu box (sudo apt-get install
> python-gtk2, but it's installed by default anyway) or on Windows XP
> machine (double click on installer icon). "Simple user" is not an idiot
> either and if she can read English, she wouldn't have hard time too.
> 
> The rumours on "problems installing GUI toolkits" are greatly exagerated
> IMO.

It might not be a big deal for your own computer,
but if you are distributing software professionally
to a bunch of customers, things get more complex.

Let's say your customers use RHEL4 for instance. If you
would like to use a recent PyGTK, this means that the
GTK libs in RHEL4 aren't new enough. Upgrading GTK will
force you to upgrade a bunch of other libraries as well.

That means that the system will no longer be the vanilla
RHEL4 with your additions. Bugs might pop up in other
applications on the system than yours, because they
assumed other versions of shared objects. You can
(perhaps) install the newer versions of the libs in
non-standard locations and set LD_LIBRARY_PATH to
that location for your program, but that means that
things brake fairly easy, and if you for instance have
a larger system, where Python scripts relying on this
new PyGTK are started from a Python interpreter embedded
in some big application, this big application will also
see the newer versions of all those shared objects that
PyGKT pulled in. Unless you are very careful, other
programs that you start up from within your application
(maybe it's possible to spawn a new shell from your app
with the embedded Python interpreter and start arbitrary
applications from there) will also get the non-standard
shared objects.

If you just install the shared objects the new PyGTK rely
on in the standard locations, you have probably removed
security patches and bug fixes added to the software by
Red Hat from the system. Any application might cease to
work, and the customer might have problem getting support
from Red Hat on the system. You might end up with a lot
more support and maintenance work than intended, or get
very unhappy customers.

Now imagine that you have half a dozen other platforms
besides RHEL4 on x86_64 that you need to support...

This is a problem you need to deal with if you develop
software for Unix. It's not impossible to solve all these
problems, but there is certainly a cost in this. If you
handle it well, there is a cost in testing and adapting
the systems. If you don't handle it well, there might
be a big cost in handling emergencies and dealing with
unhappy customers or users.



More information about the Python-list mailing list