[PATCH] python plugins in BZRPATH using Command structure

John A Meinel john at arbash-meinel.com
Thu May 12 07:53:33 BST 2005


Martin Pool wrote:
> On 11 May 2005, John A Meinel <john at arbash-meinel.com> wrote:
>
>>mbp at sourcefrog.net wrote:
>>
>>>On 10 May 2005, John A Meinel <john at arbash-meinel.com> wrote:
>>>
>>>
>>>>The attached path adds support for searching the BZRPATH env variable,
>>>>and finding .py, .pyc, .pyo files therein.
>>>
>>>My first reaction is that this is a bit too magical, but I suppose
>>>it's OK.
>>
>>I'm not sure what you consider too magical, just that putting a file in
>>a directory and the command shows up? (after setting BZRPATH).
>
>
> My slight discomfort was at mixing files that are run as external
> programs, and files that are loaded into the bzr namespace.  For
> example I can imagine someone wanting to write an external plugin in
> Python if they didn't want to learn the API.  I guess here they can
> not have the .py prefix.

Well the way the ExternalCommands interface works, is that if they had
the .py, they would have to type it. So I believe with my plugin code:

bzr myplug # run through import and cmd_myplug
bzr myplug.py # run through ExternalCommands

I actually wanted to use the .bzp extension, because I thought it was a
good extension, but it would require doing something trickier than just
"__import__".

>
> One way to avoid this would be to have a separate variable, say
> $BZRLIBPATH.

I also thought of BZRPLUGINPATH, though I prefer it BZR_PLUGIN_PATH

Any reason why we chose "BZRSTUFF" rather than "BZR_STUFF"?

>
>
>>We could put them under a separate namespaces, like:
>>bzr plugin myplugin ...
>
>
> No, that would defeat the purpose of seamless extension.  We do need
> the opposite though, 'bzr builtin commit' so that you can wrap commit
> and get back to the original.
>

If the only real criticism is that it re-uses BZRPATH, then it is a
single line correction to make it use whatever you would like.

...

>
>>Why the name "revert". The nice thing about "undo" is that it has an
>>opposite with "redo". you could say revert/redo I guess, or have some
>>sort of flag for revert to say put back the things I reverted. But I
>>can't figure out a nice name for that flag.
>
>
> A few reasons: firstly svn and other tools call it 'revert'.  Secondly
> in tla although it's called 'undo' it is not really a general undo as
> we are used to in other programs, but rather it only undoes a specific
> class of actions (changes to the working copy).  You can't, for
> example, use undo to undo a commit, and (iirc) undo after a merge will
> undo both the merge and any other changes.  More generally, in tla
> undo will often fail just when you have got your tree into a wierd
> state and need it most, which I think is an argument for a very simple
> and reliable revert.
>
>

So are you thinking that "bzr revert" always restores you to the last
committed tree state (possibly on a per file basis), and if possible,
creates a revert log, which can then be replayed.

Does that mean it reverts an "bzr add", I assume so, and from your
earlier statements it wouldn't delete the added file.

This may start to cause problems if you revert "bzr mv" since there
might be a file sitting there already, and this would overwrite it.

The nice thing about tla undo is that if you change your mind, you can
get back to where you were. But I agree that you need a way to fix your
working tree when a changeset may not be possible.

What if bzr revert tried to do a changeset undo first, and if that
fails, just does a forced one?

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 251 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20050512/9c7e86bc/attachment.pgp 


More information about the bazaar mailing list