[Merge] lp:~bzr/bzr/412930-plugin-path into lp:bzr

[Vincent Ladeuil]

Switching to list, this is out of the
https://code.launchpad.net/~bzr/bzr/412930-plugin-path/+merge/10458
patch scope anyway (but see there for context if needed).

>>>>> "bialix" == Alexander Belchenko <bialix at ukr.net> writes:

    bialix> Vincent Ladeuil пишет:

<snip/>

    jam> site-specific.

    bialix> I understand, it was light joke. But it was not very good joke. Move on.

Rats, I hate missing jokes :)

<snip/>

    jam> It only really exists on Linux
    >> 
    >> Wrong.

    bialix> Really?

Yes, OSX, xBSD and windows have one, only bzr.exe haven't :-D

    >> The get_python_lib() doc string in distutils says:
    bialix> [...]
    >> 
    >> On linux it can be 'dist-packages' or 'site-packages' in the
    >> python hierarchy.
    >> 
    >> On mac it's 'Lib/site-packages' but again the installers may be
    >> wrong here (I don't know them enough to be sure, they may well be
    >> right).
    >> 
    >> On os.name == "nt" (windows right ?) it seems to be
    >> 'Lib/site-packages'.

    bialix> Yes, so there is no distinction between "site" and
    bialix> "core" for Windows?

Yes there is, 'core' is defined everywhere that's the bzr own
plugins, lp, netrc_credential, etc (ok, only those two :)

'site' well, defined as above but currently set to None for win32.

    bialix> Because if I run bzr from sources current
    bialix> bzrlib/plugin.py (as I know) even don't try to load
    bialix> plugins from
    bialix> C:\PythonXX\Lib\site-packages\bzrlib\plugins

    bialix> And perhaps it's right? No? Why?

That's the question. It can be used internally by bzr.exe to
represent the bundled plugins (qbzr, bzr-svn, you name it)
without storing them at the same place than core.

Use case ?

Say we have a windows user saying: I can't access lp for <whatever reason>.

We can't *today* ask him to run:

  bzr --no-plugins <command> lp:<path>

because, well, because lp: is handled by a plugin.

But if they were stored in a 'site' directory, we could ask to run:

  bzr --plugins=-site  <command> lp:<path>

and that will rule out any plugin related problem.
  


    bialix> If yes, what should be the right thing if I run bzr
    bialix> 3.0 from sources and have installed bzr 2.x in
    bialix> site-packages? Do you think they will be compatible?
    bialix> Quick responses on IRC reveal that it's not.

There are cases were it's valid, there are other were it's
not. It depends a lot about how we define 'site' on windows and
how we define it for the various contexts (bzr.exe, python
installers, running from sources).

The problem itself is not fully sorted out even on linux, but I
think it's worth discussing it including the windows side of
things.

May be we need to add more type of directories (with the proposed
patch they will be trivial to add), I don't know.


    >> So, as I understand it, it makes no sense for bzr.exe

    bialix> For bzr.exe there is only "core" plugins I
    bialix> think. They are installed as $(INSTALL_DIR)\plugins\,
    bialix> e.g. C:\Program Files\Bazaar\plugins

    >> (but we may
    >> want to say it's 'All Users/Application Data/Bazaar/Plugins')

    bialix> I'm recall vaguely it was even discussed. But
    bialix> honestly: I don't want this. Actually the less places
    bialix> bzr will use to look for plugins the faster its
    bialix> startup time will be. Because on Windows it makes
    bialix> huge difference if you need to read 1 file of 10MB
    bialix> and 100 files of 100K. The less disk IO the faster
    bialix> application.

Performance shouldn't block convenience for those who want it.

    >> and
    >> when running from sources (or from easy_install when it will
    >> work), we may want to activate it (in addition to 'All Users/...')

    bialix> I have no opinion on using bzr in easy_install way. I
    bialix> love bzr.exe and think it's the best we have today.

:-D

    >> In the mean time, I kept the compatibility with previous versions
    >> and add the win32 check that I accidentally removed in my patch.

    bialix> If you return this code back then I should not worried?

I think so. Any behavior change should be a bug.

    >> Feedback welcome even if I think that should be the subject of
    >> another submission are there are certainly tweaks to be done in
    >> the windows installers.

    bialix> I'm still trying to understand what question I should
    bialix> answer.  I hope said above will help you. Ask me more
    bialix> and preferably directly, I'm not subscribed on merge
    bialix> proposal comments.

I still think the 'site' directory definition is the weakest part
of our get_standard_plugins_path() (even if my proposed patch
address some cases).

I'd like feedback from any bzr packager about what should or
should not be part of that default plugin path and what bzr
itself should take into account and what the distributions
can/could/should handle themselves[1].

  Vincent

[1]: But keep in mind that using a plugin to modify that path
     won't work :-)