standalone installer should suggest to make paramiko the default ssh client for bzr

[Alexander Belchenko]

Often when windows users have problems with bzr+ssh/sftp access I suggest them to use paramiko as default ssh client by setting environment variable BZR_SSH=paramiko.

I think it's worth to automatize this in our standalone installer: along the checkbox to add bzr directory to PATH we may suggest adding BZR_SSH=paramiko to environment variables.

We already have required infrastructure in bzr.dev/tools/win32/bzr_postinstall.py script. We just need to add here corresponding action(s) and hook it in the Inno Setup installer.

[Alexander Belchenko (bialix)]

E.g. see https://bugs.launchpad.net/qbzr/+bug/628368

[John A Meinel (jameinel)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.)

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.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyGZxYACgkQJdeBCYSNAAPGtwCgimfKrRWoU3xDXeqcjYDG9vLG
cCoAoJD/TIX+xLz10BswV+4FecvZcdME
=EgdP
-----END PGP SIGNATURE-----

[Alexander Belchenko (bialix)]

Another related bug: https://bugs.launchpad.net/bzr/+bug/632988

[Alexander Belchenko (bialix)]

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.

[RayH (ray-hunter)]

Maybe I can add a usage case to help you judge what is appropriate behaviour.

There seems to be an implicit assumption amongst bzr develpers that a development environment and a target production environment are the same thing. e.g. usernames, packages, paths etc. are common.

In our case they aren't.

We mainly write perl code, with a fair bit of MySQL, java, javascript etc. thrown in.

All of these language are portable and can run on either Linux or Windows or MAC OS X whatever.

BZR is an ideal choice for us (thanks) because
1) it is cross platform
2) it allows local repositories to support a truly distributed development
3) it is very efficient
4) it allows extensive branch and merge for maintaining multiple customer specific versions of code
5) it allows secure transports into customer environments.

5) is becoming pretty important for us: we actually don't just use bzr for code development, but also for code distribution and installation.

That isn't unique by any means. Bugzilla do pretty much the same now.

It makes software version upgrades a snap. You just do a bzr update to get the latest perl code on the target machine from the central repository, and then run a local (perl) installer script to update local DB tables etc. as appropriate: no more tarballs or installers or package managers. You could even consider using a crontab to automate this sort of upgrade, or trigger it via a cgi script if you're brave enough.

So that assumption about dev and production being even vaguely similar is quite dangerous for us. The target customer environment generally isn't much under our control, so there could be all sorts of openssh implementations installed on the target production machine (either used for other purposes, or as a hosted webserver.) The usernames are almost always completely different too. And the way of setting up the SSH transport to the central repository is invariably different (sometimes direct SSH, sometimes via a putty plink tunnel, sometimes via http, sometimes via a proxy server etc. etc.)

That's our motivation for having a "stand-alone" bzr installer. We'd like to be able to set up the bzr transport connection to our central repository separately from other code packages that may do other things in the produciton environment (like synch databases or data files to other customer machines in the production environment using e.g. cygwin /rsynch).

[RayH (ray-hunter)]

Oh yes. One more advantage of using bzr to distribute code....

If the customer wants to make any local customisations to templates or code etc. these changes are also kept under version control, and perhaps more importantly, they generally do not get munged or lost if we make a minor update our side e.g. adding another HTML Template hidden variable to a customer's input form, whilst they've changed their company logo.

[Martin Pool (mbp)]

Thanks for the background, Ray, and I'm glad you're enjoying bzr. So
the concrete upshot from that is that you'd like the configuration of
ssh to be more selfcontained within bzr, and isolated from the ssh
configuration of the machine/user bzr is running within?

--
Martin

[RayH (ray-hunter)]

Exactly. That's my view of the appropriate default behavior.

I can appreciate the other side of the argument that SSH is not an integral part of bzr, so this might have to be a configurable item.

[Alexander Belchenko (bialix)]

John Arbash Meinel пишет:
> ...
>> 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.
>>
>
> Setting the environment variable effectively disables the
> auto-detection. I don't see it as particularly different, just forcing a
> different case by default, which is what we would do anyway...

The difference will be in the optional nature of setting env variable.
We're asking user whether he wants to add bzr to the PATH,
I'm going to do the same re paramiko settings.