Sorry I missed the thread when it was 'hot' and I know everyone is tired sick of it :), but allow me to present my point of view. On Wed, 2005-01-19 at 22:32 +0100, Murray Cumming wrote: > On Wed, 2005-01-19 at 21:14 +0000, Mark McLoughlin wrote: > > > The application developer knows by > > > a) Reading the pygtk documentation, which says what versions of Python > > > work with pygtk. > > > b) Seeing what works. > > > > So, I'm using pygtk for the first time at the moment and I have to > > admit that this whole conversation is just a bit bewildering to me... > > > > You want me to put > > > > #!/usr/bin/python2.3 > > > > in my scripts rather than > > > > #!/usr/bin/env python > > No, I think you are meant to do > #!/usr/bin/env python2.3 > though I'm not quite sure what that does. > > The pygtk developers created this example to make it easier: > http://cvs.gnome.org/viewcvs/gnome-python/pygnome-hello/ > I think this is what it achieves. OK. I agree with Murray and disagree (sorry) with Johan Dahlin and James Henstridge here. Applications startup scripts should specify the python version in the #! line. _However_, the pygnome-hello example is lacking in one respect. It only looks for a single Python ABI version, but it should potentially look for more than one version. I hope to fix that sometime. What is important is that, once selected, the Python version is locked in the application startup script. This is so that I can safely install Python 2.4, make it the default version, and not break existing pygtk applications. But I think developers should be encouraged to try to make applications work with at least the latest two python versions. configure.in should look at available versions and see if any one matches a version known to work, then write that version to the init script. For desktop modules wanting to use pygtk, I'd recommend that all modules in a given release use the same python version. But I don't see any reason why in the following GNOME release we couldn't select a new Python version, and make any (minor) fixes to make all modules work with this version. What Sean wants is only relevant to non-open-source modules, or simply unmaintained ones. He wants the application that he got 5 years ago to keep working on his brand new distribution. What the bindings rules say is, we guarantee that is possible to make it work, but you may need to install older pygtk/python. It is not reasonable for distributions to install by default all python versions known to man in the unlikely case an older version is needed to run a unmaintained module. I agree that maybe we should expect distributions to have packages of older versions of Python available online, just in case they are needed. But let's not either 1) install all versions by default, or 2) lock a version forever. But do not confuse the situation of closed source / unmaintained module with modules in GNOME desktop. The latter should be required to be maintained, thus are able to work around any python incompatibilities that may arise. Conclusion. More demands than these from bindings are not reasonable. And any modules in GNOME desktop are implicitly maintained, thus do not suffer from any problems mentioned in this thread. Again, I apologize for potentially reviving this thread, but all happened very fast and I couldn't say anything before.. :| -- Gustavo J. A. M. Carneiro <gjc inescporto pt> <gustavo users sourceforge net> The universe is always one step beyond logic.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature