Code review comment for lp:~ian-clatworthy/bzr/411413-plugin-disable

>>>>> "robert" == Robert Collins <email address hidden> writes:

    robert> On Mon, 2010-01-11 at 07:48 +0000, Ian Clatworthy wrote:
    >>
    >> Another is '' (disabled) vs 'use this one if multiple exist'.
    >>
    >> I went with the latter because it was more powerful. I'm fine going
    >> with the first one (though it's a shame to dumb this feature down
    >> given your preferred alternative isn't likely to make the 2.1 IIUIC).

    robert> By default we search two places for plugins:
    robert> - the installed library
    robert> - homedir

Add:
- the system-wide installed plugins

While the later has been more or less a hack when it was
introduced, the net result is that it is now *used* that way when
people use distributions where bzr *and* plugins are installed
system-wide.

    robert> and homedir wins over system installed plugins (or at
    robert> least it used too :)).

That's still the default: user/core/site (see
bzrlib.plugin.get_standard_plugin_path).

Windows is the only platform were things are blurry because
there is no concept of 'site' there.

I consider it a bug but couldn't get agreement from bialix nor
jam on how to address that in a simple way. The causes were 1)
windows doesn't have a package manager nor a standardized
directory layout, 2) the installer add plugins in bzrlib.zip
(mixing the 'core' and 'site' directories into a single one).

<snip/>

    robert> So it seems to really be just disabling that is
    robert> really useful for the use cases you're putting
    robert> forward here (though I consider it a bug if a plugin
    robert> needs to be 'not loaded' to be unintrusive: we
    robert> shouldn't be shipping problematic plugins by
    robert> default.)

Or we do, we should allow users to install fixed versions.