[MERGE] windows standalone installer creates and uses "plugins" directory for system-wide plugins (#129298)

Alexander Belchenko bialix at ukr.net
Tue Nov 27 22:16:12 GMT 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CC to Bazaar ML.

Kevin Light пишет:
> ----- "Alexander Belchenko" <bialix at ukr.net> wrote:
>> Kevin Light пишет:
>>> ----- "Alexander Belchenko" <bialix at ukr.net> wrote:
>>>> This patch in the same time bug fix (wishlist-fix actually)
>>>> and improvements. IMO this change is worth to include to 1.0.
>>>>
>>>> With this patch standalone bzr.exe will able to load plugins
>>>> from C:\Program Files\Bazaar\plugins. This directory will
>>>> be used therefore as location for system-wide plugins.
>>>> Currently there is no easy way to install plugins for standalone
>>>> bzr.exe for system-wide usage (beside using BZR_PLUGIN_PATH
>>>> environment variable): because all python modules (compiled
>>>> to pyc) stored inside one big library.zip. Now we have this
>>>> option.
>>> Might I suggest C:\Program
>> Files\Bazaar\lib\site-packages\bzrlib\plugins instead?  This would
>> allow cross-platform plugin archives to be unpacked in the Bazaar home
>> folder just as if they would be installed into the python home.
>>
>> What do you mean by "cross-platform plugin archives"?
>> AFAIK, all plugins distributed as python package or python module.
>> Mostly as tar.gz archives. Some (like QBzr) provide nice windows
>> installer.
> 
> I apologize for attempting to "fix" the wrong problem.  
> You are correct in that the shorter plugins location is better
> and after working with my problem some more I have realized
> that the plugins location is not critical and is rather flexible with pure python bzr plugins.

Actually, the main reason to do not put plugins inside /lib subdirectory
is because I'd like to keep this dir private to bzr.exe itself.
This directory contains all libraries bzr required. User should not
touch anything there.

> My problem has more to do with the bzr.exe's inability to load the additional 
> Python packages required by more complex plugins such as bzr-svn and bzr-gtk.

Standalone bzr.exe is called standalone exactly for this reason: it does
not require any additional library to allow bzr.exe works in base
configuration.

> Ultimately these plugins should be packaged like QBZR, 
> however the difficulty of packaging some of these plugins
> keeps the developers from making a Windows installer (bzr-svn for example).

I don't see here problem in packaging. It's pretty simple
task to collect required python libraries and write
wrappers for compiled extensions. And it should be done only once.
AFAIK, building windows installer when you have all dependencies
collected in some dedicated folder, is simple and easily automated
task either on Windows or on Linux (with NSIS installer compiler).

I see problem only in lacks of human resources of developers/maintainers
for bzr-gtk and bzr-svn. I say about the fact that none of them
use Windows and therefore can't support it properly on this platform.

I could provide required changes for bzr-gtk to make it work
with bzr.exe, because all dependencies is clear for me.

In fact year ago I've used bzr-gtk and Olive during couple of
months. But one of problem with bzr-gtk for me was in its diff:
it relies (relied? from README it's not clear that something changed)
on some GTK library (gtksourceview IIRC)
that simply do not ported on Windows. So diff is always
black and white on Windows. But I like colors. I can have b/w diff
in the terminal.
Another bit is amount and the size of required libraries.
Another reason for me to do not use bzr-gtk is my overall
feeling about GTK on Windows. (It's my personal taste of course.
I know many windows people who like GTK interface very much.)
So in fact I'm simply not enough motivated to maintain
and build installers for each release of bzr-gtk.
I could provide instructions but there should be
dedicated bzr-gtk windows maintainer.

About bzr-svn: I simply don't understand dependencies
of this plugin. Jelmer said svn sources should be patched
and rebuilt. It's not trivial task IMO. Or may be we need
just wait long enough to see release 1.5 of svn and
all problems will gone in a flash?

If someone will provide complete list of required packages
and where I can download it, and how I can test that
bzr-svn actually works (selftest is enough for me)
I could start working on creating solution for bzr-svn
(installer script, instructions). I like to automatize
such tasks so one needs only type `make` and all job
will be done. There is no black magic in creating windows
installers. Especially when you have automated build
system.

But again, if there is no ready-to-use third party python
packages for svn that bzr-svn required, and someone should
build it themself, I think such person will be able to
produce bzr-svn windows installer as well.

So here we have stalemate: I have too little knowledge about
svn libraries and what bzr-svn required, and Jelmer has
no ability to work on Windows for this problem. We need
someone who willing to help here and who able to run Windows
without loathing.

Jelmer already sent RFH = request for help (? - IIUC), but
still no one answering to his call.

> I have been hacking at a solution, which is a plugin, 
> which is why I had an opinion.
> What I have found is that setup.py, even when run on bzr plugins,
> will create an installation location of <python>\Lib\site-packages.
> This is true for any of the dist (dist, bdist, bdist_wininst) options.

It's completely correct behavior.

>   However being able to drop the bzr plugins into the plugins folder
> completely eliminates the reason for my opinion.

> The question that has surfaced for me is: What is the plugin loading order 
> with your proposed patch?
> My hope would be that c:\program files\bazaar\plugins
> would load before $APPDATA/bazaar/2.0/plugins.

No. Sorry, but your hope is incorrect here, IMO.
Loading plugins from APPDATA should take higher precedence,
because c:\program files\bazaar\plugins is dedicated to system-wide
plugins and $APPDATA/bazaar/2.0/plugins is plugins for current user only.

Users without admin rights should be able to change set of plugins
for their own environment. So "their own" plugins should be
loaded first. Otherwise let's imagine following situation:
in system-wide location you're have plugin "foo v.1.0"
with some bug that broke all your work.
But you're able to download new version of "foo v.1.1" with proper
bugfix. So, if you have not access to c:\program files\bazaar\plugins
you simply put new version in your home directory and go on.
Otherwise you need nag your admin to make this work for you.

Maybe I'm slightly wrong in details of this imaginary situation,
but IMO all software try to follow idiom when current user settings
overrides system-wide ones.

I hope I shed some light on the state of plugins support in bzr.exe.
(This e-mail turns a bit longer than I can predict.)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHTJcszYr338mxwCURAoM/AJ9CxtWiGOSfCA+rWoUfn7hhyN/sPgCgjRkE
M+zNGCCYHuqF/vMcItoKz6o=
=ALbw
-----END PGP SIGNATURE-----



More information about the bazaar mailing list