bzr selftest fails on a machine without paramiko

[Matthieu Moy]

The following patch (by jam) fixes the problem.

=== modified file 'bzrlib/tests/test_sftp_transport.py'
--- bzrlib/tests/test_sftp_transport.py 2006-08-25 07:31:08 +0000
+++ bzrlib/tests/test_sftp_transport.py 2006-08-30 06:40:29 +0000
@@ -403,6 +403,8 @@

     def setUp(self):
         TestCase.setUp(self)
+ if not paramiko_loaded:
+ raise TestSkipped('you must have paramiko to run this test')

     def test_delay(self):
         from bzrlib.transport.sftp import SocketDelay

[Robert Collins (lifeless)]

On Mon, 2006-09-11 at 14:41 -0500, John Arbash Meinel wrote:
> Robey Pointer wrote:
> >
>
> ...
>
> >>> bzr is 0.9-0ubuntu2, the rest of the system is up-to-date edgy.
> >>
> >> Looks to me like paramiko is being unfriendly here. We should probably
> >> catch this and turn it into either ENOENT or a 0 length file, depending
> >> on what Robey says is happening.
> >>
> >> affects /products/bzr
> >
> > It looks like the underlying server connection vanished. I should
> > translate that into an SSHException for the next version, but I'm not
> > sure if that should be treated as ENOENT or an empty file. It probably
> > should just be treated as a "fail" error and let the user retry. (In
> > other words, same as now, but without the stack trace.) ;)
> >
> > robey
>
>
> Well if the connection goes away, then we would probably prefer to
> translate it into ConnectionError on our end.
> The problem is that this is happening at 'read()' time, not at 'get()'
> time. So it can't be wrapped by the transport. Either the transport
> needs to return a wrapped file object, that translates read()
> exceptions, or the bzr core needs to start understanding transport
> specific errors.
>
> So this may be a reason to introduce a TransportFile, which is
> file-like, only it handles translating a transport specific exception
> into a generic exception.

Well, all servers can fail badly during read(). Its just that we're
getting an error we dont understand during this particular one.

I think a global TransportFile is probably not needed, but we may need
one for sftp to solve this bug with current paramiko (which is all we
can be sure users will have).

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

[Vincent Ladeuil (vila)]

>>>>> "jam" == John Arbash Meinel <email address hidden> writes:

    jam> Robey Pointer wrote:
    >>

    jam> ...

    >>>> bzr is 0.9-0ubuntu2, the rest of the system is up-to-date edgy.
    >>>
    >>> Looks to me like paramiko is being unfriendly here. We
    >>> should probably catch this and turn it into either ENOENT
    >>> or a 0 length file, depending on what Robey says is
    >>> happening.
    >>>
    >>> affects /products/bzr
    >>
    >> It looks like the underlying server connection vanished.
    >> I should translate that into an SSHException for the next
    >> version, but I'm not sure if that should be treated as
    >> ENOENT or an empty file. It probably should just be
    >> treated as a "fail" error and let the user retry. (In
    >> other words, same as now, but without the stack trace.) ;)
    >>
    >> robey

    jam> Well if the connection goes away, then we would probably
    jam> prefer to translate it into ConnectionError on our end.
    jam> The problem is that this is happening at 'read()' time,
    jam> not at 'get()' time. So it can't be wrapped by the
    jam> transport. Either the transport needs to return a
    jam> wrapped file object, that translates read() exceptions,
    jam> or the bzr core needs to start understanding transport
    jam> specific errors.

    jam> So this may be a reason to introduce a TransportFile,
    jam> which is file-like, only it handles translating a
    jam> transport specific exception into a generic exception.

http faces the same kind of problem, the reads can (today for
pycurl, in the future for urllib) occur outside the scope of the
transport, so having a TransportFile, if not necessary now, can
solve future problems.

+1 on the concept

   Vincent

[John A Meinel (jameinel)]

this was fixed in bzr-0.11

[Markus F.X.J. Oberhumer (markus-oberhumer)]

I'm reopening this bug, as bzr selftest without paramiko stopped working in bzr 0.90 and 0.91rc2 again:

mfx@minerva:~/tmp/q/bzr-0.91rc2 > ./bzr selftest
testing: /home/mfx/tmp/q/bzr-0.91rc2/bzr
   /home/mfx/tmp/q/bzr-0.91rc2/bzrlib (0.91.0candidate2 python2.4.4.final.0)

bzr: ERROR: Unable to import paramiko (required for sftp support): No module named paramiko