Visual Studio integration

[Klaus Hartke]

Hey,

thank you very much for all the replies. So there are two more options:

(5) Embedding CPython into a C/C++ dll
     - and -
(6) Writing one or more Bazaar plugins as helpers

I think both are very interesting and probably more viable than the
IronPython approach. I'll comment on each in a moment.

John Arbash Meinel wrote:
> [bzr uncommit] probably isn't supported by the standard VCS
> integration

Visual Studio's standard version control mechanism is Visual SourceSafe.
Although it is possible to write custom version control providers, the
API exposed is SourceSafe centred, expecting a Lock-Modify-Unlock model
instead of, say, Copy-Modify-Merge.

My prototype is following the AnkhSvn approach by ignoring the version
control API and providing all actions in form of a regular add-in (which
is free to add any menu entry and/or toolbar item it needs, plus a lot
more).

John Arbash Meinel wrote:
> I'm guessing that the "easy" way to get a plugin in the latest Visual
> Studio is if you tie into their .NET apis. I would guess VS itself is
> running on their .NET interpreter.

Visual Studio is still based on good ol' COM and in fact allows add-ins
to be developed both with COM and .NET. But would think about developing
bzr in C if you have the option to do it in Python? :)

But here comes a good point I wasn't aware of yet:

Alexander Belchenko wrote:
> I'm sure you can embed CPython interpreter into some C++ programs/dll
> (I don't know about C#) and then use such wrapper to communicate with
> bzrlib directly.

C# is a wonderful language for interfacing with C. I tried embedding
CPython into a C# program last night -- and got the Very High Level
Embedding example [1] running within minutes.

A few minutes later I discovered the "Python for .NET" package [2] which
apparently provides not only a feature-complete CPython wrapper allowing
to instantiate any class and call any method from a hosting application,
but also allows the Python code running inside to call back into the
hosting application and to access the entire .NET API (including
creation and display of windows).

>From what I've seen so far, bzr's command-line interface appears to be
just a thin layer on-top of bzrlib and concentrated almost exclusively
in builtins.py. So embedding CPython would just require to re-implement
that module and replace its command-line bits with a GUI. Or one could
even do that in Python itself!

Very interesting. And it would run under Linux (with Mono), too (which
is a killer argument in my opinion).

Of course, one would still have to deal with interactive input required
for SSH logins:

John Arbash Meinel again:
> There are some options here. One is if you get the latest bzr, it should
> have support for using Putty's 'plink' as its ssh program. And I think
> plink can be configured to pop up a dialog for interaction.

According to [3] plink provides an option to disable all interactive
prompts ('-batch') which would at least prevent wrapping applications
from getting stuck. Maybe there is another option hidden somewhere else
to pop up a dialog...

John Arbash Meinel suggested:
> bzrlib.transport.ssh.ParamikoVendor and implements a custom auth
> command. Or even just monkey patches bzrlib.transport.ssh._paramiko_auth
> to use a Win32 dialog.

I guess that'd the way to go.

Regarding IronPython:

John Arbash Meinel wrote:
> This is my favorite idea, as the bzrlib api is quite rich versus what
> you can get from a command line.
> 
> There are a couple limitations that I'm aware of with IronPython.
> 
> 1) Last I tried it wasn't python2.4 compatible. But I thought I've read
> about updates to 2.4 compatibility. This is one of the bigger hurdles,
> as we use decorators and generator comprehensions in our code.
> 
> 2) Lack of common modules like "sha".  I don't know specifically which
> modules IronPython is missing, but running the test suite would probably
> point them out. Hopefully some of them would be easy to update.

There is a IronPython distribution called 'IronPython Community
Edition' [4] which provides enhancements and add-ons for IronPython
like, for example, a "sha" module and paramiko. But it's still missing
many, many features.

Here are the problems I identified so far, but I guess I didn't even
reach the point where decorators or generator comprehensions are used:

- 'file()' does not support 'buffering' parameter
- 'open()' does not support mode 't' (a no-op anyway)
- "Class with slots and getattr not compatible" [5] (lazy_regex.py)
- module 'zipimport' is missing
- module 'zlib' exists but is incomplete (lacks partial flushes)
- some problems with lazy imports
- exceptions have a 'clrException' attribute instead of 'errno'
- 'os.access()' is missing
- an unidentified number of modules for which bzrlib provides fallback
  (like cElementTree) are missing

John Arbash Meinel continued:
> 3) At this moment, we make very few calls directly to C functions. The
> only ones I'm aware of are the Win32 api LockFileEx. Which I would hope
> is exposed by IronPython in some form. Again, this should be as simple
> as implementing another Lock type, and inserting it as the default lock
> implementation.

Yes, I think one could write a module in IronPython which exposes this
functionality.

But, I guess Szilveszter is right:

Szilveszter Farkas wrote:
> I wouldn't call [IronPython] an alternative, or a possibility yet...
> (both on Linux and Windows)

So it's the same situation as with Jython.

This is the other option I didn't think about:

Guillermo Gonzalez wrote:
> At this moment all go well with this aproach, but if I had to do
> something *really* tricky, I already have been thinking about writing
> one or more bazaar plugin's as helpers to the Eclipse plugin. And add
> them to the BZR_PLUGIN_PATH variable in the env of the process (from
> the java side). I not test this yet, but maybe you can solve some of
> those problems, (i.e: interactive input) with this aproach

I could imagine developing some kind of standardised, machine-readable
format (based on XML?) to communicate to the bzr process. You could
start the process once, and communicate with it using that protocol like
in one huge interactive session.

As with the Embedded CPython approach, I guess you would have to write a
second implementation of builtins.py which, instead of human-readable
text, outputs XML and then waits for the next command.

The advantage of this approach over every other is of course, that it
would benefit the integration into both Eclipse and Visual Studio at the
same time.

John Arbash Meinel:
> Klaus Hartke wrote:
> > Would implementing one of these options (#2 or #3) make a viable
> > GSoC project? My general aim would be a platform-independent library
> > written in C# and/or IronPython, plus Bazaar integration into Visual
> > Studio.
> 
> I would hate to see you re-implement bzrlib in C#. I'm guessing it
> would be easier to get the few standard library functions that we need.
> (You could implement sha in python as a "slow but functional" sort of
> step)

Re-implementing the whole bzrlib in a different language is of course
not an option. (And I already gave up any plan to write a parser for
that obscure format you're using in bazaar.conf and locations.conf.)

The two new options are both very interesting. I'm actually quite hooked
by the CPython approach and will explore its possibilities the next few
days. Maybe I can integrate util.configobj into my existing prototype as
a first step.

Regards,
Klaus



[1] http://docs.python.org/ext/high-level-embedding.html
[2] http://pythonnet.sourceforge.net/
[3] http://the.earth.li/~sgtatham/putty/0.59/htmldoc/Chapter7.html#plink
[4] http://fepy.sourceforge.net/
[5] http://lists.ironpython.com/pipermail/users-ironpython.com/2006-
November/004131.html