[RFC] Suggested directory names for branches

John Arbash Meinel john at arbash-meinel.com
Thu Apr 12 14:29:34 BST 2007


Aaron Bentley wrote:
> Hi all,
> 
> There's a bit of mismatch between Bazaar and launchpad, because
> launchpad encourages branch names to end in "/trunk" and Bazaar defaults
> to using the last component as the directory name.
> 
> And further, some projects have urls that do not end with the desired
> directory name.
> 
> Does it make sense for branches to provide a "suggested dirname"?
> 
> For example,
> 
> $ bzr branch http://bazaar.launchpad.net/~bzr/bzr-gtk/trunk
> 
> would produce a directory named "gtk".
> 
> This would work better with our current plugin development practices,
> which encourage people to install plugins by branching.  On the other
> hand, it's more config data to worry about.
> 
> Really, I'd rather fix launchpad than Bazaar, but realistically, I
> figure I have more chance of fixing Bazaar.
> 
> Thoughts?
> 
> Aaron

Well, it happens with anything with branch naming. If you have
"project/branches/foo" you are going to get 'foo' when you checkout.
Which when you are doing multi-branch development is actually reasonable.

I think the primary thing is that *plugins* should know what name they
are installed as. They aren't even happy with "gtk.ab" or even a
pythonic "gtk_ab".

So I think plugins are a pretty special case, where when branching
someone else's code you want to end up with a special name locally.
(There is the other issue with LP that you have to write names with
dashes which won't ever work as plugin names, and that we have a
convention of 'bzr-foo' though when you install the plugin it should be
called 'foo').

In the past, I thought having plugins contain a member in __init__.py
which said what the real path should be would work, but I understand
that won't update the standard python search rules, which allows plugins
to depend on eachother.

Currently the only real way to do it in __init__.py to do:

if __name__ != 'bzrlib.plugins.expected_name':
  warning('This plugin is installed as %s'
	  ' but should be installed as expected_name'
          % (__name__,))

I certainly think that 'gtk' should do that, since it has a very direct
expectation of its name.

I think most of my plugins use relative names to avoid this.


I kind of like the idea of having 'branch.conf' have a 'suggested name'.
However, it seems like a fairly involved change just because of how our
plugins work...

If we consider it a hint, we wouldn't need to have a new branch format.

John
=:->


PS> One other remote possibility using 'bzr branch lp:///foo' which will
create it locally as foo. Though that doesn't work for "lp:foo" which
tries to create "lp:foo" (and can't because that is on the http
supermirror), and it also doesn't work with a naming convention of
'bzr-foo'.



More information about the bazaar mailing list