users overservations on the plugin handling

[Martin Pool]

2009/8/25 Tim Michelsen <timmichelsen at gmx-topmail.de>:
> Dear BZR-developers,
> I have been using BZR since autumn 2007 (I think so). At least quite for
> some time.
> I like it for many reasons. The main are:
> * cross-platform
> * TortoiseBZR (hasn't been there from the beginning)
> * flexibility (I can have it on low-end FTP...)
>
> I have encountered difficulties here and there. Filed bugs and Q&A. But
> generally it works well.
> The interesting is that I cannot use bzr to pull from Launchpad behind a
> Squid-based firewall.
> As I still do like it, I will try with my feedback from a user PoV to
> improve it.
>
> Here I wanna share my perception of the plugin system. As BZR matzres, I
> think it could receive some improvement:
>
> The BZR plugin system has some shortcomings from the user point of view:
>    * no common specifications / minimum requirements
>        * plugin help
>        * command help
>        * crossplatform compatibilty & no info if used on wrong platform
>    * the following could be done to improve these:
>        * it should be easy to upgrade (all) plugins
>        * the GUI (Windows) could have a plugin manager that takes plugins
> from
>            online repository (c.f. QGIS)
>        * many plugins have external dependencies on other python modules
>            (e.g. svn relys on subvertpy.py). But these are not tracked.
>        * plugins should be crossplatform or at least state the system and
> show a message if used
>            on the wrong platform
>        * why not use eggs or easy_install?
>
> I can see that there are 2 blueprints with similar target:
> Add setuptools support for bzr and Launchpad:
> https://blueprints.launchpad.net/bzr/+spec/bzr-setuptools-support
> A plugin manager with functionality similar to apt, fink, and so on.:
> https://blueprints.launchpad.net/bzr/+spec/bzr-plugin-manager

I think those are all good questions.

> I am not a frequent reader of this list. What about putting up a blieprint
> on this?

So you can certainly add to those blueprints if you want, but I think
generally speaking writing blueprints is not a good way to get things
moving.  Writing code is best.  Rehashing things that have already
been discussed is not so good.  Perhaps we need something that's not
quite a blueprint but rather a wishlist, in which users can make sure
their ideas are covered.

-- 
Martin <http://launchpad.net/~mbp/>