Windows standalone installer should create plugins directory

>Asking on IRC gave me the following answer:
>"put it somewhere else and set the BZR_PLUGIN_PATH env variable", which worked out great, but I think it would be nice if the Windows standalone installer, while it was installing Bazaar, created a Plugins directory in my Bazaar installation directory, and set the environment variable for me.

No, it should not do this.
Windows policy states that applications should not store any settings or configurations files (or any auto-generated files) in Program Files directory. This is our case: each plugin is python sources, and during import Python interpreter will create and save compiled bytecode (*.pyc) files.

Mozilla Firefox and Thunderbird is very good examples of windows applications: their store extensions (== plugins) in

C:\Documents and Settings\%USERNAME%\Application Data\Mozilla\Firefox\Profiles\xxxxx\extensions\
C:\Documents and Settings\%USERNAME%\Application Data\Thunderbird\Profiles\xxxxx\extensions\

Another bad side effect of placing plugins in C:\Program Files\Bazaar\Plugins subdirectory is the fact that uninstaller know nothing about installed plugins and don't know is plugins should be uninstalled or not.

Only one right solution for me (already mentioned in the past, IIRC) is to allow Bazaar looking for plugins in
C:\Documents and Settings\All Users\Application Data\bazaar\2.0\plugins directory in addition to
C:\Documents and Settings\%USERNAME%\Application Data\bazaar\2.0\plugins.

I think this problem could be solved also with some nice GUI tool that allows users explore list of plugins on Bazaar website, download them and install automatically in right location. I started bzr-config application, but plugins support is not implemented yet.

BTW, Mercurial use another approach: their install standalone hg.exe not in C:\Program Files\, but in C:\mercurial instead, and expect plugins in a subdirectory of C:\mercurial.

But actually both approaches have theirs cons and pros.

I would suggest that plugins are neither settings nor configuration files, and while plugins are currently distributed as source, there's no reason they could not be distributed as .pyc files, so that they weren't even auto-generated. (And further, they're not even auto-generated by bazaar, but by Python.) Since it would be the installer creating the Plugins directory, I believe that the uninstaller should feel free to blow away anything in it when uninstalling.

As I mentioned in my original case, having Firefox and Thunderbird put extensions in %USERNAME% specific locations is quite annoying to me.

The C:\Documents and Settings\All Users\Application Data\bazaar\2.0\plugins directory is less annoying, but I still feel that it's not really the correct solution. (Although I acknowledge that you have a good reason for suggesting it, plugins still feel to me less like configuration, and more like application code, and should therefore live with the rest of the application code.)

(As a third option, what about storing them in C:\progra~1\Common Files\Bazaar\Plugins? There seems to be a bunch of other Vendor-ish stuff there...)

On the next topic, please tell me that I, as the user, can select where I want to install Mercurial. I have a real beef with programs that think they need to live at the root of my drive. Honestly, they're not that important. They can live in Program Files, or Program Files\Version Control, or however I've set up my box. :P

Finally, I'ld like to offer the example of Windows Media Player, which has various things that can be plugged into it.
C:\Program Files\Windows Media Player>dir /ad
 Volume in drive C has no label.
 Volume Serial Number is ****-****

 Directory of C:\Program Files\Windows Media Player

06/07/2007 10:25 AM <DIR> .
06/07/2007 10:25 AM <DIR> ..
03/07/2007 02:56 PM <DIR> Icons
06/07/2007 10:25 AM <DIR> Network Sharing
03/07/2007 02:53 PM <DIR> Sample Playlists
03/07/2007 02:53 PM <DIR> Skins
03/07/2007 02:56 PM <DIR> Visualizations

Now, I think we can both agree that Icons, Skins, and Visualizations are, if anything, less like application code than Plugins. And therefore, if Microsoft thinks it's okay to store Icons, Skins, and Visualizations in a subdirectory of Program Files, Bazaar shouldn't have any conceptual problems storing Plugins there as well.

Heck even Internet Explorer puts plugins in it's Program Files directory...

C:\Program Files\Internet Explorer>dir /ad
 Volume in drive C has no label.
 Volume Serial Number is ****-****

 Directory of C:\Program Files\Internet Explorer

04/07/2007 10:08 AM <DIR> .
04/07/2007 10:08 AM <DIR> ..
03/07/2007 02:53 PM <DIR> Connection Wizard
03/07/2007 04:36 PM <DIR> en-US
03/07/2007 04:13 PM <DIR> MUI
13/07/2007 03:38 PM <DIR> PLUGINS
04/07/2007 12:58 PM <DIR> SIGNUP

Have I produced enough examples to change your mind yet?

Because I feel that I experienced enough to use FAR or Windows/Total Commander, I usually have no devout trembling to look or change files/dirs in Program Files, but only because I reinstall Windows too much times. So for me your arguments have weights, and probably we can compile plugins sources to *.pyc when installing it to C:\Program Files\Bazaar\Plugins.

But I think more important thing is to have nice installer for plugins. And better some universal installer, because too much people will care about managing special binary distribution of theirs plugins, most of them lives as bzr branches at launchpad.

So, after we have right tool to install/uninstall plugins, we can add option to our standalone installer. But not vice versa. Maybe in the future we bundle some popular plugins with standalone installer itself. Maybe it will be simpler solution.

OK, you convince me, but I really think we need some sort of additional tools to easy install/uninstall plugins (at least for windows users). And with this tool your original wishlist will be less important, what you think?

I whole-heartedly agree, although as a stop-gap measure, my request still stands. (I think it would be a reasonable increase in usability for a small amount of effort, which would tide us over until we implemented the larger-scoped, better-thought-out fix of adding a plugin installer.)

And with the tool, even if it's just "bzr plugins get [--all-users] plugin_name", we can put the plugins anywhere we choose (at which point "C:\Documents And Settings\All Users (or %USERNAME%)\" would be perfect).

The rest of this is sort of bikeshedding, but here are my suggested command lines, if possible.
bzr plugins get [--all-users] plugin_name # Get a new plugin by name from launchpad.
bzr plugins update plugin_name # Update a previously-gotten plugin by name from launchpad.
bzr plugins remove plugin_name # Remove a previously-gotten plugin.
bzr plugins # List all the plugins.

Just a comment about the standalone windows installer: the documentation for it on the official bzr download page (http://bazaar-vcs.org/WindowsDownloads) is incorrect and vague as to the proper location to put the plugins. It states:

=====
[...]
This is the easiest way to install Bazaar even if you don't already have Python. You can also use most of the Bazaar plugins (excluding GUI plugins) as long as they are installed in your home directory. If you have Python 2.4/2.5 installed, and you want to install all dependencies yourself, please use the Python-based installer linked to below.
[...]
=====

I don't see a link on that page for feedback, so I hope it's okay to use launchpad to note this.

> Just a comment about the standalone windows installer: the documentation for it on the official bzr download page (http://bazaar-vcs.org/WindowsDownloads) is incorrect > and vague as to the proper location to put the plugins. It states:
> ...
> I don't see a link on that page for feedback, so I hope it's okay to use launchpad to note this.

Actually that page is a wiki, almost anyone could edit it. I fix it.

QBzr is the first plugin that provide standalone installer compatible with bzr.exe.
It's a good sign, and good plugin.
Because bzr.exe lacks ability to install plugins system-wide, I'm willing to implement such support as proposed by bwinton.
Then others (or me) could create standalone installers for bzr.exe

err, typo: Then others (or me) could create standalone installers for plugins compatible with bzr.exe

Sent to pqm.