bzr-windows team mailing list archive

[Alexander Belchenko <bialix@xxxxxxx>]

Hi,

I was the man who start building installers in the 2006 and did it till 
2008. Several times I've heard complains about difference between 
standalone bzr.exe installer and python-based installation. Several 
times I've seen in Bazaar Sprint Notes that core bzr devs want to throw 
away standalone bzr.exe distribution and only provides python-based ones.

The main point it seems people don't understand difference between two.
And feedback from DeeJay (see his mail "Windows Installer documentation 
review") indicates that it's still the problem. But is really it's the 
problem with installer per se?

Well, I don't think it's THE problem per se, but maybe there is need for 
good installation guide to select between two. I'm have problems to 
articulate this in English though. But I'll try to explain different 
reasons to have 2 installers. And maybe you will help to write something 
useful for newbies.

1) If you don't know anything about Python and entire Python universe it 
seems natural that you'd like to have as small as possible steps to 
install bzr as software. And you don't care is it written in Python or 
Java or C# or plain C.

2) If you know about Python and have Python installed then you may want 
to install bzr as usual python software (via python-based installer) OR 
you don't want care about installing all dependencies bzr has (paramiko, 
pycrypto, PyQt4, etc etc) and just want to use it. In this case it's 
very likely you'd like to use standalone bzr.exe.

3) My own experience: I'm using Python since 2004. I'm writing in Python 
many helper utilities for my job. I really love Python. But!
Every time I want to install or test some Python application (especially 
GUI application!) I *don't* want to go the hard way and install bunch of 
dependencies libraries (PyGTK/wxWindows/PyQt4/Twisted/whatever).

4) Bazaar positions itself as CLI application AND library (bzrlib). This 
is very important point! If you're using it only as CLI application you 
don't care is it standalone bzr.exe or just python script.

5) If you start using another tools that using bzr as library you ALWAYS 
need python-based version. Examples of tools that uses bzrlib library: 
Bzr-Trac plugin, Loggerhead (!)

6) When we talk about Loggerhead we should treats it as separate tool 
that uses bzrlib library. I've heard that Loggerhead can be used as 
plugin? Does it works on Windows with python-based installation as plugin?

7) Compatibility of plugins with standalone bzr.exe. This is THE 
problem. But don't need to think this is a fatal illness of the 
standalone bzr.exe. This problem *has* solutions. Several possible 
solutions. I list them:

a) Include everything from Python standard library into bzr.exe. This is 
not quite solution because some plugins required third-party libs.

b) Plugins with extra dependencies should provide special installer for 
the plugin with required dependencies bundled there. QBzr has provided 
such installer year before it was included into bzr.exe. And people 
happily using it. This is the best solution I can imagine of. But as 
usual the problem here that most plugins written by Linux hackers who 
don't want or don't care about creating special installer with 
dependencies. Or they don't have Windows. Anyway, I've seen this too 
often and I've learn that either those plugins should have special 
Windows maintainers or complains about incompatibility with bzr.exe will 
be forever.

But why you think that's bzr.exe-only fault?!

c) Introduce better support in bzr.exe for installing third-party 
libraries required by plugin. E.g. add support for import from 
extralibs/ subdirectory, not only from library.zip. This is really 
tricky, especially because py2exed applications (bzr.exe) don't support 
setuptools eggs. So if some plugin require dependencies available as 
eggs or relying on setuptools -- there is no way and people should use 
python-based installer instead.

8) I know one plugin that require special installer when user want to 
use python-based bzr: and this is (drum-roll here!) most popular 
bzr-svn! It's a blessing that it's included into bzr.exe installer. 
Because bzr-svn author Jelmer don't want to build special installer for 
poor windows souls. Such installer was built in the past by one man 
(forgot the name) but there is now nothing.

9) So I think good guide should help, something like this:

* If you're first time using bzr and you don't need special plugins -> 
you can use bzr.exe

* If you have Python installed and you don't need special plugins -> use 
either python-based version or bzr.exe

* If you want use bzr with some tools (listing of known tools that 
require bzrlib) or use some bzr plugins (listing of plugins incompatible 
with bzr.exe) -> you should use python-based version.

10) For python based version there is need for comprehensive 
installation guide explaining all dependencies and caveats. This guide 
could be created based on WindowsInstall wiki page and BzrWin32Installer 
page.

11) Let's look at competitors. Most closest is Mercurial: it's also 
written in Python and also distributed as standalone application. It has 
the same problems as bzr.exe. There is 2 installers for Windows:

* CLI-only standalone hg.exe with official extensions inside.
* TortoiseHg all-in-one installer with additional libs inside.

So they even don't have python-based version. At all.

In any case if you want to use non-official extension with any installer 
and such installer lacks some libs -- you've got the same problem as 
with bzr.exe. And this is inevitable.

So the main difference: hg has a lot of "official" extensions (30+) that 
supported by hg core devs. What about bzr?

----------------------------
Resume.

So if you still don't understand why for there is 2 types of windows 
installers then I've failed and I can't explain better. Those who do 
understand -- you'd better share your experience and help here.