[MERGE] optionally install tbzr binaries with bazaar binaries on Windows

[Mark Hammond]

> I've seen installers that only need to reboot if there was actually a
> file it couldn't modify. Do you know if that is the case here? I 
> certainly prefer them to ones that always say "reboot to continue" 
> even when there was nothing held open.

It only reboots if files were actually in use.

> ^- In the long run, it seems to make a lot more sense to change this
> function
> into:
> 
> from tbzrlib import setup_fu
> return setup_fu(*args, **kwargs)
> 
> In other words, make the packaging for tbzr exist in the tbzr project,
> and we just import that into the bzr packaging.

Agreed.

> ^- So it sounds like anything we checkout into bzrlib/plugins/* will
> get
> bundled in as a plugin. Is that correct?
> 
> I'm a bit worried, then, that your explicit whitelisting of only .py,
> .pyd,
> .dll is incomplete. Certainly there *could* be required data files
> (.ico,
> .png, .dat, etc.)
> 
> I know you didn't write it, but I would be much more interested in
> having ways
> to ask plugins how to install themselves, and have *them* figure out
> what
> files need to be included. This also extends well for how to get TBZR
> bundled
> with the rest.

Yes, I agree with that too.  eg, the bzr-svn plugin already knows what DLLs are necessary, so it should be able to communicate that to the top-level installer.

> As this is the code that *you* need to build the complete win32
> installer for
> bzr-1.6, I'll merge it. I just would like you to take my comments into
> consideration for a post 1.6 release. I really get the feeling that the
> installer is a bit crufty, as people just keep bolting on "this one
> other
> thing" to be installed, rather than really laying it out in a nice
> manner.

Understood.

> And yes, it is good to write this against the 1.6 branch. I can merge
> it there, and then I'll merge 1.6 into bzr.dev as part of the final
> release.

Excellent - thank you.

Mark