command that batches bzr and qbzr commands

[John Arbash Meinel]

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

Michael Gliwinski wrote:
> On Monday 26 Jul 2010 16:55:08 John Arbash Meinel wrote:
>> Michael Gliwinski wrote:
> ...
>>> Basically an example of what I'm trying to do is write a command which
>>> downloads some files, imports them (like bzrtools' import) and then
>>> launches a qcommit dialog pre-filled with certain message and author,
>>> etc.
> ...
>>> The question of batching commands though is something I've been meaning
>>> to ask regardless.  Basically sometimes you don't need to dive into
>>> lower-level APIs when all you need is to batch functionality already
>>> encapsulated in CLI cmd_ classes.  But basically is OK to run commands
>>> in cmd_ classes from another cmd_ class?
>> Many plugins already do this. You may want to look at some of them,
>> because sometimes the setup rules have been a bit unclear. (Some setup
>> code expected run_argv_aliases() to be called, which usually doesn't
>> happen when running from another command). However that might have been
>> sorted out.
> 
> OK, I'll look into that.  Would you remember off top of your head an example 
> of one such plugin by any chance?

IIRC bzrtools's cbranch command calls cmd classes directly.

>> That said, if there isn't an internal api to do the things you want to
>> do at the Command level, we consider that a bug. The commands should be
>> just a command-line glue to get you into domain objects (Branch, etc).
> 
> OK, good to know.
> 
>> I'll also note that Command level interaction means re-opening branches,
>> etc, and I don't think that will allow connections to be held open. So
>> you may end up with multiple ssh handshakes.
>>
>> Short answer: yes you can do it, but we'd like to know why you want/need
>> to.
> 
> Yes, I'm aware of that shortcoming.  I actually rarely think of going this 
> route with core bzrlib API, and really love working with it.
> 
> In this specific case I implemented the transfers using transport API 
> (awesome, BTW), then the import using bzrtools.upstream_import.do_import which 
> says it's meant for UI so I'm not sure if that was right thing to use but 
> didn't really have time to find out what would need to be decoupled from it.
> 
> Next I wanted to add an optional stage where commit message, author, etc. 
> where filled in but still allow people to review the changes.  I thought 
> qcommit would be great for that as you can pretty much do most reviewing from 
> there.
> 
> Now that I had a look at qcommit code though, I see that just running the 
> cmd_qcommit code wouldn't allow me to do what I want as it creates the window 
> and runs QApplication directly from run() method, so there is no place where I 
> could inject setting the required properties.
> 
> So now I'm trying to figure out how to use QBzr's CommitWindow from my command 
> without inheriting from QBzrCommand (I still want the import to run without 
> GUI, but if GUI is available then offer the option of using it).  If anyone 
> has any pointers on that BTW, I'd really appreciate them (I had a look at the 
> now disabled merge --qpreview which seemed to do sth like that but it seems 
> approach used there wouldn't work anymore).
> 
> So I suppose the short answer to why I'd want this at times is: to quickly 
> hack up something that works, before find time to get into the details and 
> make it work properly ;)
> 
> Thanks,
> Michael
> 
> 

Sure. You may also want to look for us on irc.freenode.net #bzr. People
tend to hang out there, and you may get faster response times.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkxO81kACgkQJdeBCYSNAAP94ACfdv5m7I7VoCbzAnHnXkMYcZuG
gnMAnRwmyg3XS7x5YgTGLjW7sWQu6FmO
=gp9Z
-----END PGP SIGNATURE-----