After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 587764 - Revert excessive simplifcation of gconf support
Revert excessive simplifcation of gconf support
Status: RESOLVED FIXED
Product: jhbuild
Classification: Infrastructure
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Jhbuild maintainers
Jhbuild QA
Depends on:
Blocks:
 
 
Reported: 2009-07-04 17:49 UTC by Owen Taylor
Modified: 2009-07-06 04:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Revert excessive simplifcation of gconf support (1.50 KB, patch)
2009-07-04 17:49 UTC, Owen Taylor
reviewed Details | Review

Description Owen Taylor 2009-07-04 17:49:10 UTC
Commit 7e4e50c6387517769001241fd57e3e5f9aecc296 accidentally
changed the behavior and instead of creating a merged GConf
path file, created a GConf path file that only looked in the
JHBuild directory.
Comment 1 Owen Taylor 2009-07-04 17:49:57 UTC
Created attachment 137840 [details] [review]
Revert excessive simplifcation of gconf support
Comment 2 Frederic Peters 2009-07-05 18:30:29 UTC
[I was offline so I couldn't review it earlier, and sorry I introduced errors when I simplified that patch.]

> + for line in inp:

I am not sure when files became iterators over their lines, could you replace it by inp.readlines() to be sure it works with older Python releases ?

> +   if line.find('/etc/gconf') != -1:

I would prefer 'if '/etc/gconf' in line'.
Comment 3 Owen Taylor 2009-07-05 19:11:37 UTC
One note is that this was a literal revert back to DanW's original version of that code section, but we can certainly merge in some cleanups as well as necessary.

(In reply to comment #2)
> [I was offline so I couldn't review it earlier, and sorry I introduced errors
> when I simplified that patch.]
> 
> > + for line in inp:
> 
> I am not sure when files became iterators over their lines, could you replace
> it by inp.readlines() to be sure it works with older Python releases ?

Python 2.3

 http://www.python.org/download/releases/2.3/highlights/

 File objects are now their own iterators. This makes multiple interrupted
 iterations over the same file more reliable. The xreadlines() method and 
 module are now deprecated.

You don't support anything older than that, right?
 
> > +   if line.find('/etc/gconf') != -1:
> 
> I would prefer 'if '/etc/gconf' in line'.

Sure, happy to make that change.
Comment 4 Frederic Peters 2009-07-05 19:20:40 UTC
There is still support for Python < 2.3 in jhbuild/monkeypatch.py, but then I guess it could be removed and 2.3+ required.  No hard feeling on this.

As I won't have much online presence these days, please apply any cleanup you want, and then commit, gnome-shell is important.
Comment 5 Owen Taylor 2009-07-05 22:23:33 UTC
Pushed:

commit ed323685c1fee3b0c2d0948d3cf3a2bfa80651eb
Author: Owen W. Taylor <otaylor@fishsoup.net>
Date:   Sat Jul 4 18:45:13 2009 +0100

    Revert excessive simplifcation of gconf support
    
    Commit 7e4e50c6387517769001241fd57e3e5f9aecc296 accidentally
    changed the behavior and instead of creating a merged GConf
    path file, created a GConf path file that only looked in the
    JHBuild directory.
    
    Also cleanups:
    
     - Maintain nominal compat with Python-2.2
     - Use 'needle in haystack' rather than 'haystack.find(needle) != -1'
 
Python-2.3 was released July 2003. (Only actual incompat I saw in a scan
through the code was a single use of basestring, but I'm sure nobody has
tested with 2.2 for a long time.)
Comment 6 James Henstridge 2009-07-06 04:32:52 UTC
For what it is worth, the "needle in haystack" syntax was only added in Python 2.3.  Prior to that, it would raise an exception if you tried to search for anything but a single character with that method.

If this change doesn't generate any bugs/complaints, it probably means that there are no jhbuild users with Python 2.2.  If that is the case, then you may as well drop support for it and use features from newer versions.

To give some perspective, Python 2.3 was released almost 6 years ago and 2.4 over 4.5 years ago.  Either of those would make good baseline versions to target.