Bazaar Windows Installers

Bug #631611
Comment #4

Comment 4 for bug 631611

Revision history for this message

Alexander Belchenko (bialix) wrote on 2010-09-08: Re: [Bug 631611] Re: standalone installer should suggest to make paramiko the default ssh client for bzr

John A Meinel пишет:
> On 9/6/2010 9:16 AM, Alexander Belchenko wrote:
>> E.g. see https://bugs.launchpad.net/qbzr/+bug/628368
>
> If we are going to make it the default, I wouldn't use the env var, I
> would just stop detecting regular 'ssh' (aka openssh, etc) if
> 'sys.platform == "win32"'. Much easier to get correct, IMO.
>
> And I there was a discussion on this a while back. (With Mark Hammond.)
> I originally felt that people with ssh in their path probably have it
> configured. (since you *do* have to take explicit manual steps to get
> there.) But it seems a lot of people install cygwin and put it in their
> path, without wanting to use ssh for stuff. (or for some things but at
> least not for bzr.)

It's my impression as well.

As I understand svn required to set some env variable to enable svn+ssh
support? If so we should not be shy of doing the same.

> Also, the power of having an agent (since ssh-agent doesn't run on
> Windows) is quite a game changer.
>
> I'd probably be fine just skipping the ssh detection unless the user
> explicitly requests it.
>
> Though any sort of 'change the default behavior' is going to bite some
> group that had been relying on it.

OK, thinking about this a bit more:

1) Disabling ssh detection inside bzrlib and use paramiko by default is
much much easier, but it sounds like major change for me. Therefore it
makes sense to do the change for 2.3 only with big red flashing warning
in What's New.

Am I wrong here?

2) Fixing windows installer does not sound as major change for me. It
will require to change postinstall script (which still in the bzr.dev
branch and this is kinda sucks) and Inno Setup installer. Users of
python-based installers won't be affected by this change and anyway will
require to set BZR_SSH variable. But as I can see from download
statistics they're not majority.

So I'd prefer to do implement no2 for 2.2 (and maybe 2.1.x too) as short
term solution, and implement no1 for 2.3.

John A Meinel пишет:
> On 9/6/2010 9:16 AM, Alexander Belchenko wrote:
>> E.g. see https://bugs.launchpad.net/qbzr/+bug/628368
> 
> If we are going to make it the default, I wouldn't use the env var, I
> would just stop detecting regular 'ssh' (aka openssh, etc) if
> 'sys.platform == "win32"'. Much easier to get correct, IMO.
> 
> And I there was a discussion on this a while back. (With Mark Hammond.)
> I originally felt that people with ssh in their path probably have it
> configured. (since you *do* have to take explicit manual steps to get
> there.) But it seems a lot of people install cygwin and put it in their
> path, without wanting to use ssh for stuff. (or for some things but at
> least not for bzr.)

It's my impression as well.

As I understand svn required to set some env variable to enable svn+ssh 
support? If so we should not be shy of doing the same.

> Also, the power of having an agent (since ssh-agent doesn't run on
> Windows) is quite a game changer.
> 
> I'd probably be fine just skipping the ssh detection unless the user
> explicitly requests it.
> 
> Though any sort of 'change the default behavior' is going to bite some
> group that had been relying on it.

OK, thinking about this a bit more:

1) Disabling ssh detection inside bzrlib and use paramiko by default is 
much much easier, but it sounds like major change for me. Therefore it 
makes sense to do the change for 2.3 only with big red flashing warning 
in What's New.

Am I wrong here?

2) Fixing windows installer does not sound as major change for me. It 
will require to change postinstall script (which still in the bzr.dev 
branch and this is kinda sucks) and Inno Setup installer. Users of 
python-based installers won't be affected by this change and anyway will 
require to set BZR_SSH variable. But as I can see from download 
statistics they're not majority.

So I'd prefer to do implement no2 for 2.2 (and maybe 2.1.x too) as short 
term solution, and implement no1 for 2.3.