olive vs bzr-gtk

[Martin Pool]

On  3 Sep 2006, Jelmer Vernooij <jelmer at samba.org> wrote:
> > If you don't like what I'm doing or how I'm doing, please tell me :)
> Let's try to discuss first what kind of integration between olive and
> bzr-gtk we are aiming for. I see the following possibilities:
> 
>  (1) Integrate the two into one package. 
>  (2) Keep two separate packages but move some of Olive's classes to
> bzr-gtk and then "import gtk.*" from Olive
>  (3) Keep two separate packages but "import olive.*" from bzr-gtk
> 
> Personally, I would like to avoid (3) as it would make people using
> bzr-gtk use extra dependencies. I would prefer (1), but if we decide to
> go that direction, that leaves us with a couple of other issues.
> 
> In the case of (1), what name to use? I would prefer bzr-gtk as name for
> the plugin and olive as name for the standalone utility. 
> 
> There are a couple of things in Olive at the moment that I would like to
> avoid in an integrated plugin. For example, I think a low-level
> changelog isn't very useful and I'd rather avoid the backend/ directory
> especially as all this stuff will be gtk-specific.

I would prefer to have just one integrated package.  

It's very obvious what something called 'bzr-gtk' would do (at least to
Linux users), 'Olive' somewhat less so though it is a nice name.
Jelmer's suggestion could work well.

At a technical level I would recommend against having a package called
'gtk.*', as it seems like it would clash with Python's standard gtk
library.  Could it be bzrgtk instead?

Let's look at backend.py:

__init__.py
	empty
commit.py
	Seems to contain a version of cmd_commit and also (oddly)
 	cmd_push?
errors.py
	Some exceptions, almost all of which do not seem GUI-specific
fileops.py
	add, mkdir, move, remove, rename, status: seem mostly like
 	wrappers around corresponding WorkingTree functions
info.py
	diff, info, revno, whoami, etc, similar
info_helper.py
	get_location_info, get_missing_revisions_working,
	get_working_stats, etc: return dictionaries with information about 
	various bzr objects
init.py
	branch, checkout, init: also seem to replace builtin commands?
ui.py
	seems to be gtk-specific code to implement the UIFactory
update.py
	reimplementations of pull, missing, update

On my quick look through there does seem to be a lot of duplication of
functions that are already provided inside bzrlib.  I'm sure Szilveszter
added these for a reason, but I'd like very much if we could avoid
having two implementations of operations like 'pull', etc. 

The goal has always been that bzrlib should have an api that suits GUIs.
At the moment many high-level operations like pull are only available in
a function specific to the command line, but that can  be fixed, so that
there is one layer which does strictly the command-line interpretation,
and another which does the high-level operation.

So, Szilveszter, can you say something about how you came to have this,
or what you would need in bzrlib to avoid having it in backend?

-- 
Martin