[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