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

[John Arbash Meinel]

Alexander Belchenko wrote:
> 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?

Sounds fine to me. I do think the paths clutter it up a bit.

> 
>> 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.
> 
> 

John
=:->