Too bad I only discover the above issue (with a proper fix) today (I think this came up from debian but can't find the relevant discussion anymore) :-/
If I'm reading this correctly, paramiko 1.16.2 will fix the compatibility issue.
>> @Chad: which ubuntu release ?
> Which release of what? You mean perhaps "yakkety"?
Yeah, I meant ubuntu but checked with rmadison afterwards:
python-paramiko | 1.16.0-1 | xenial | all
python-paramiko | 1.16.0-1 | yakkety | all
Which would mean paramiko was able to enter xenial despite dep8 tests that should have caught that regression :-/
Anyway, in the mean time, as a workaround, you may be able to bzr+ssh instead of sftp (which is inherently slower) ?
> There's some crazy paramiko version testing that determines whether prefetch is called at all.
Yup, dating from when prefetch was introduced in paramiko, clearly more confusing than relevant theses days.
> Maybe another test is in order.
I was hoping for paramiko to not break backwards compatibility:
https:/ /github. com/paramiko/ paramiko/ issues/ 676
Too bad I only discover the above issue (with a proper fix) today (I think this came up from debian but can't find the relevant discussion anymore) :-/
If I'm reading this correctly, paramiko 1.16.2 will fix the compatibility issue.
>> @Chad: which ubuntu release ?
> Which release of what? You mean perhaps "yakkety"?
Yeah, I meant ubuntu but checked with rmadison afterwards:
python-paramiko | 1.16.0-1 | xenial | all
python-paramiko | 1.16.0-1 | yakkety | all
Which would mean paramiko was able to enter xenial despite dep8 tests that should have caught that regression :-/
Anyway, in the mean time, as a workaround, you may be able to bzr+ssh instead of sftp (which is inherently slower) ?