Merge lp:~snaggen/bzr/gio-transport into lp:bzr
| Status: | Superseded |
|---|---|
| Proposed branch: | lp:~snaggen/bzr/gio-transport |
| Merge into: | lp:bzr |
| Diff against target: |
600 lines (+585/-0) 2 files modified
bzrlib/transport/__init__.py (+3/-0) bzrlib/transport/gio_transport.py (+582/-0) |
| To merge this branch: | bzr merge lp:~snaggen/bzr/gio-transport |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| John A Meinel | 2010-05-13 | Needs Fixing on 2010-05-24 | |
| Robert Collins (community) | Needs Information on 2010-05-23 | ||
| Parth Malwankar | 2010-05-04 | Abstain on 2010-05-12 | |
|
Review via email:
|
|||
This proposal has been superseded by a proposal from 2010-05-27.
Commit Message
Add a gio based transport using gio+ as a prefix to get at the gio logic.
Description of the Change
This adds a transport using the gnome lib gio for underlying operations. This means that it will be possible to use dav,smb,obex locations to store branches.
The current state is that the things pointed out by Martin Pool in the following mail has been fixed.
https:/
The only outstanding issue is that one test case fails:
bzrlib.
AssertionError: UnicodeEncodeError not raised
This is due to the fact that the push_file method just uses the ConnectedTransp
| Martin Pool (mbp) wrote : | # |
On 5 May 2010 14:24, Parth Malwankar <email address hidden> wrote:
> Review: Needs Fixing
> Hi Mattias,
>
> I don't know much about GIO but had a few general comments.
>
> 121 + #if 'gio' in debug.debug_flags:
> 122 + # mutter("stat size is %d bytes" % self.st_size)
>
> 329 + #if 'gio' in debug.debug_flags:
> 330 + # mutter("GIO put_file wrote %d bytes", length);
>
> Maybe the above can be removed completely.
Maybe they should be. My feeling is that people are welcome to leave
in debug-flag guarded mutter statements as long as they could possibly
be useful for someone to turn them on again when debugging a problem
in this area -- especially if you would ever ask a user to run with it
and show the output.
--
Martin <http://
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> On 5 May 2010 14:24, Parth Malwankar <email address hidden> wrote:
>> Review: Needs Fixing
>> Hi Mattias,
>>
>> I don't know much about GIO but had a few general comments.
>>
>> 121 + #if 'gio' in debug.debug_flags:
>> 122 + # mutter("stat size is %d bytes" % self.st_size)
>>
>> 329 + #if 'gio' in debug.debug_flags:
>> 330 + # mutter("GIO put_file wrote %d bytes", length);
>>
>> Maybe the above can be removed completely.
>
> Maybe they should be. My feeling is that people are welcome to leave
> in debug-flag guarded mutter statements as long as they could possibly
> be useful for someone to turn them on again when debugging a problem
> in this area -- especially if you would ever ask a user to run with it
> and show the output.
>
Sure, but commented out debug flag code doesn't help anyone :).
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkv
QzcAoNopBqe/
=p5Gk
-----END PGP SIGNATURE-----
| Mattias Eriksson (snaggen) wrote : | # |
ons 2010-05-05 klockan 13:24 +0000 skrev Parth Malwankar:
> Review: Needs Fixing
> Hi Mattias,
>
> I don't know much about GIO but had a few general comments.
>
> 121 + #if 'gio' in debug.debug_flags:
> 122 + # mutter("stat size is %d bytes" % self.st_size)
>
> 329 + #if 'gio' in debug.debug_flags:
> 330 + # mutter("GIO put_file wrote %d bytes", length);
>
> Maybe the above can be removed completely.
Yes I'll remove those.
> 134 + self.mounted = 0
> 135 + """Set the base path where files will be stored."""
> 136 + if not base.startswith
>
> The association of the string at 135 above is not very clear.
I have changed the wording and moved some things to make it clearer
> In the put_file function. I see there is a nested try with the outer one catching Exception and closing fout and f.
> You could consider using just the inner try (with gio.Error) and closing these in a finally clause. Use of Exception is generally not a good idea as its a catch all.
> Maybe something like:
>
> try:
> # do processing
> except gio.Error, e:
> # handle gio error
> finally:
> if not closed and fout is not None:
> fout.close()
> if f is not None:
> f.delete()
Yes that is very much more readable... I didn't know about the finally
statement, that is very nice. Thanks for showing this.
> For append_file. I noticed that both the nested try handle gio.Error. Is it possible to combine these into one. I also noticed that 'length' is defined inside the inner try and used outside. Can it happen that due to an exception, length is not defined and we try to use it outside?
The length inside the inner try isn't used, so I removed that. length
(from the new part of the file) and the reslut from the stat operation
(on the already existing file) is used to verify that the append
operation is resulting in an expected file length.
And since the stat of the existing file may file with a ERROR_NOT_FOUND
which is legal I have the nested try to handle that and ignore that
error. This is due to the cludge I have to use since the gio append_to
is broken and corrupt files.
> Some lines are going beyond 80 chars, it would be good to break them. PEP 8[1] is used for coding style in bzr code base.
Fixed those.
//Mattias
| Parth Malwankar (parthm) wrote : | # |
Thanks Mattias. This looks good to me from a python perspective.
One minor tweak is that backslash (\) need not always be used to break lines. E.g. line breaks are handled cleanly when broken at comma in a function call. There are other implicit rules like this.
foo("a",
"c",
"d")
There is a good summary of line joining here:
http://
As I don't know much about GIO I will abstain from voting. Maybe someone else can give it a deeper look.
| John A Meinel (jameinel) wrote : | # |
I think it would make the most sense to move "gio/__init__.py" to just "gio.py" since you don't have any other modules anyway.
248 + while self.mounted == 0:
249 + gtk.main_
^- We'd rather not import gtk if we can help it. Andrew Bennetts specifically pointed out it changes global state (not in good ways). Specifically:
>>> import sys
>>> print sys.getdefaulte
'ascii'
>>> import gtk
>>> print sys.getdefaulte
'utf-8'
And that affects any time you do unicode(str) [mostly implicitly] as it now treats those bytes as utf-8, rather than failing if it has non-ascii bytes. (We try pretty hard not to accidentally implicitly cast, but we get it wrong sometimes.)
Shouldn't there be an equivalent function to gtk.mainiteration() in gobject/etc?
I'm personally a little concerned that gio might get imported by accident (espec on platforms where it isn't available), but from what I can see you're doing it ok. We may need something like:
try:
import gio
import gtk # if we need it
except ImportError:
raise errors.
We should have similar code in transport/sftp.py for paramiko.
Otherwise the test suite will probably fail on platforms where gio is not installed.
For testing the Authentication support, would it be possible to just use the FTPServer and subclass it slightly so that you access it via gio+ftp rather than just ftp://? You'd also want a check that the dependencies are present for ftp and for gio before running that permutation.
| Mattias Eriksson (snaggen) wrote : | # |
fre 2010-05-14 klockan 07:28 +0000 skrev John A Meinel:
> Review: Resubmit
> I think it would make the most sense to move "gio/__init__.py" to just "gio.py" since you don't have any other modules anyway.
Well the problem here is that if I move it from gio/__init__.py to just
gio.py I cant do "import gio" since we have a name clash. And it is
still to early for me to figure out a good name besides gio.py for my
module.
> 248 + while self.mounted == 0:
> 249 + gtk.main_
>
>
> ^- We'd rather not import gtk if we can help it. Andrew Bennetts specifically pointed out it changes global state (not in good ways). Specifically:
>
> >>> import sys
> >>> print sys.getdefaulte
> 'ascii'
> >>> import gtk
> >>> print sys.getdefaulte
> 'utf-8'
>
> And that affects any time you do unicode(str) [mostly implicitly] as it now treats those bytes as utf-8, rather than failing if it has non-ascii bytes. (We try pretty hard not to accidentally implicitly cast, but we get it wrong sometimes.)
>
> Shouldn't there be an equivalent function to gtk.mainiteration() in gobject/etc?
I didn't know that it caused problems, I have now removed gtk and
replaced this with running my own mainloop. That also had the benefit of
getting rid of my ugly while loop waiting for things to get done.
>
> I'm personally a little concerned that gio might get imported by accident (espec on platforms where it isn't available), but from what I can see you're doing it ok. We may need something like:
>
> try:
> import gio
> import gtk # if we need it
> except ImportError:
> raise errors.
>
> We should have similar code in transport/sftp.py for paramiko.
>
> Otherwise the test suite will probably fail on platforms where gio is not installed.
I initially didn't do this since it was handled very nice by default,
but I still want the test suite to work so I have added this.
> For testing the Authentication support, would it be possible to just use the FTPServer and subclass it slightly so that you access it via gio+ftp rather than just ftp://? You'd also want a check that the dependencies are present for ftp and for gio before running that permutation.
Well the problem was that I couldn't find any of the ftp server options
for lucid, so I wasn't able to get the ftp tests to run om my computer.
| John A Meinel (jameinel) wrote : | # |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
...
> Well the problem here is that if I move it from gio/__init__.py to just
> gio.py I cant do "import gio" since we have a name clash. And it is
> still to early for me to figure out a good name besides gio.py for my
> module.
gio_transport.py comes to mind.
...
>> Shouldn't there be an equivalent function to gtk.mainiteration() in gobject/etc?
>
>
>
> I didn't know that it caused problems, I have now removed gtk and
> replaced this with running my own mainloop. That also had the benefit of
> getting rid of my ugly while loop waiting for things to get done.
>
>
...
>> For testing the Authentication support, would it be possible to just use the FTPServer and subclass it slightly so that you access it via gio+ftp rather than just ftp://? You'd also want a check that the dependencies are present for ftp and for gio before running that permutation.
>
>
> Well the problem was that I couldn't find any of the ftp server options
> for lucid, so I wasn't able to get the ftp tests to run om my computer.
>
>
I believe the python2.6 code requires:
http://
(since that is maintained, vs the medusa server.)
I don't see a package for it, Vincent would have a better idea of what
it specifically takes to set up. (He has a babune slave running on
Lucid, I'm guessing he has pyftplib set up there.) I would guess it is a
download + setup.py install. Though not quite as nice as 'apt-get
install python-ftplib', it would at least be a start.
That said, if you've manually tested auth support, I'd be willing to
merge it. Likely someone like Vincent will come along later and make
sure it is properly tested :).
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkv
4KYAoLl6dH/
=HmJq
-----END PGP SIGNATURE-----
| Mattias Eriksson (snaggen) wrote : | # |
ons 2010-05-19 klockan 21:36 +0000 skrev John A Meinel:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> ...
>
>
> > Well the problem here is that if I move it from gio/__init__.py to just
> > gio.py I cant do "import gio" since we have a name clash. And it is
> > still to early for me to figure out a good name besides gio.py for my
> > module.
>
> gio_transport.py comes to mind.
That works for me... I had planed to fix it before I pushed yesterday,
but I forgot. I'll fix it.
| Robert Collins (lifeless) wrote : | # |
John, you voted resubmit - are you happy with the changes Mattias has made?
| John A Meinel (jameinel) wrote : | # |
218 + def _mount_
219 + try:
220 + obj.mount_
221 + except gio.Error, e:
222 + print "ERROR: ", e
223 + finally:
224 + self.loop.quit()
^- This should at least be a trace.warning(), also try/except/finally isn't allowed in Python2.4, only 2.5+, so it will get rejected by PQM.
(Well, maybe, as the code may not get exercised since gio may not be installed there.)
Robert- do you know how to check if gio is available?
There is some concern about the potential to bit-rot if we don't have an auth test running, but as long as someone is actively using the code, that should get caught fairly quickly.
Overall, I think just handling the python2.4 issue, and it should be ok.
| Mattias Eriksson (snaggen) wrote : | # |
The print "ERROR is changed to raise a BzrError instead
The try/except/finally was recommended to me to make some code simpler. I didn't have it there at first. Anyway I removed that from the mount_done since it didn't really make any difference. The other place in the code requires more job.
| Parth Malwankar (parthm) wrote : | # |
> The print "ERROR is changed to raise a BzrError instead
> The try/except/finally was recommended to me to make some code simpler. I
Sorry about that. I wasn't aware that 2.4 only supported try/finally and
not try/except/finally. :)
> didn't have it there at first. Anyway I removed that from the mount_done since
> it didn't really make any difference. The other place in the code requires
> more job.
| Robert Collins (lifeless) wrote : | # |
sent to pqm by email
| Martin Pool (mbp) wrote : | # |
On 26 May 2010 18:30, Parth Malwankar <email address hidden> wrote:
>> The print "ERROR is changed to raise a BzrError instead
>> The try/except/finally was recommended to me to make some code simpler. I
>
> Sorry about that. I wasn't aware that 2.4 only supported try/finally and
> not try/except/finally. :)
np, https:/
please suggest anything else that comes up too.
--
Martin <http://
| Parth Malwankar (parthm) wrote : | # |
As this is a user visible change it should probably have a NEWS entry under 'New Features'.
| Mattias Eriksson (snaggen) wrote : | # |
I just fixed the try/catch/finally issue pointed out by John. Also added a NEWS entry.
| Parth Malwankar (parthm) wrote : | # |
Hi Mattias,
The new changes don't seem to be visible in the diff. Could you push the latest changes and set the status to "Needs Review".
The current diff has already been landed on the mainline.
| Parth Malwankar (parthm) wrote : | # |
> Hi Mattias,
>
> The new changes don't seem to be visible in the diff. Could you push the
> latest changes and set the status to "Needs Review".
> The current diff has already been landed on the mainline.
Never mind. It seems that merged branches are not scanned. I have set it to needs review for the diff.
- 5221. By Mattias Eriksson on 2010-05-28
-
Merge bzr.dev

Hi Mattias,
I don't know much about GIO but had a few general comments.
121 + #if 'gio' in debug.debug_flags:
122 + # mutter("stat size is %d bytes" % self.st_size)
329 + #if 'gio' in debug.debug_flags:
330 + # mutter("GIO put_file wrote %d bytes", length);
Maybe the above can be removed completely.
134 + self.mounted = 0 ('gio+' ):
135 + """Set the base path where files will be stored."""
136 + if not base.startswith
The association of the string at 135 above is not very clear.
In the put_file function. I see there is a nested try with the outer one catching Exception and closing fout and f.
You could consider using just the inner try (with gio.Error) and closing these in a finally clause. Use of Exception is generally not a good idea as its a catch all.
Maybe something like:
try:
fout.close( )
# do processing
except gio.Error, e:
# handle gio error
finally:
if not closed and fout is not None:
if f is not None:
f.delete()
For append_file. I noticed that both the nested try handle gio.Error. Is it possible to combine these into one. I also noticed that 'length' is defined inside the inner try and used outside. Can it happen that due to an exception, length is not defined and we try to use it outside?
Some lines are going beyond 80 chars, it would be good to break them. PEP 8[1] is used for coding style in bzr code base.
[1] http:// www.python. org/dev/ peps/pep- 0008/