[MERGE] new formatting of `bzr plugins` output.

Alexander Belchenko bialix at ukr.net
Mon Jan 21 15:57:11 GMT 2008


John Arbash Meinel пишет:
> Alexander Belchenko wrote:
>> I rework formatting of `bzr plugins` output.
>> Now I think it's much better for eyes of human beings.
> 
> I do find it easier to read, though I find this even better:
> 
> bzrtools 1.1.0
>     Various useful plugins for working with bzr.
>     C:\work\Bazaar\plugins-repo\bzrtools
> 
> launchpad
>     Launchpad.net integration plugin for Bazaar.
>     C:\work\Bazaar\mydev.packs\plugins.output\bzrlib\plugins\launchpad
> 
> multiparent
>     Implementation of multiparent diffs for versionedfile-like storage
> 
> C:\work\Bazaar\mydev.packs\plugins.output\bzrlib\plugins\multiparent.py
> 
> win32symlinks 0.92.0
>     Fake symlinks support for win32 (NOTE: slow on FAT32!)
>     C:\work\Bazaar\plugins-repo\win32symlinks

I like your variant.

I'm also thinking about show path to plugin only with -v flag, e.g.
bzr plugins -v
What do you think about -v?

> The only problem with automatically changing ".py[co]" => ".py" is that 
> there may not *be* a .py. One could certainly ship your plugins as 
> precompiled .pyo modules with all the docstrings, etc stripped out. So 
> if we do it, we probably should use "os.path.isfile()" to make sure it 
> really is present.

Actually I did this check and there is explicit test for such situation:
bzrlib.test.test_plugins.TestPlugins.test_plugin_get_path_pyc_only

> Also, I'm not sure how it would work if the .pyc file was in a .zip 
> archive.

My another patch remove support of loading plugins from zip.
So, IMO it will not be a problem.




More information about the bazaar mailing list