qconflicts says that my merge tool is not available. what should I do?

Bug #939605 reported by Alexander Belchenko on 2012-02-23
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Medium
Gordon Tyler
2.5
Medium
Gordon Tyler

Bug Description

I have WinMergeU installed on my machine and I'm able to run it from command-line as "winmergeu".

But qconflicts sais me that this tool is not available. What can I do to explain qbzr that it's actually available?

Related branches

Alexander Belchenko (bialix) wrote :

@Gordon Tyler: can you shed some light on this?

Changed in qbzr:
status: New → Confirmed
importance: Undecided → Medium
Alexander Belchenko (bialix) wrote :

Here is the screenshot.

Alexander Belchenko (bialix) wrote :

C:\Temp\qbzr>bzr version
Bazaar (bzr) 2.4.2
  Python interpreter: C:\Program Files\Bazaar\python26.dll 2.6.6
  Python standard library: C:\Program Files\Bazaar\lib\library.zip
  Platform: Windows-XP-5.1.2600-SP3
  bzrlib: C:\Program Files\Bazaar\lib\library.zip\bzrlib
  Bazaar configuration: C:/Documents and Settings/modul98/Application Data/bazaar/2.0
  Bazaar log file: C:\work\.bzr.log

Copyright 2005-2011 Canonical Ltd.
http://bazaar.canonical.com/

+ QBzr 0.22.1

Alexander Belchenko (bialix) wrote :

If QBzr (or maybe bzr?) wants to know the absolute path to winmergeu then I don't see a way how I can provide it to it?

I've tried qconfig, but there is no way to edit predefined tools. See screenshot.

Alexander Belchenko (bialix) wrote :

qconfig screenshot

Alexander Belchenko (bialix) wrote :

OK, I see. In qbzr you're using this check

elif not mergetools.check_availability(cmdline):

Which is tracked to bzrlib.mergetools.check_availability. And the latter has only simple search in PATH env variable. But in fact WinMerge is registered in the Windows registry under App Paths key, as MSDN suggested:

http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx

On my machine I have subkey

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\WinMergeU.exe

with default value:

C:\Program Files\WinMerge\WinMergeU.exe

That's what bzr should use.

affects: qbzr → bzr
tags: added: mergetools win32
Gordon Tyler (doxxx) wrote :

A quick workaround would be to add it to your system PATH. Or create a new merge tool definition with the absolute path.

Alexander Belchenko (bialix) wrote :

Actually bzrlib already has method to get application path from registry:

bzrlib.win32utils.get_app_path

Alexander Belchenko (bialix) wrote :

C:\work\Bazaar\bzr-2a\bzr.dev>py26
Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from bzrlib import win32utils
>>> print win32utils.get_app_path('winmergeu')
C:\Program Files\WinMerge\WinMergeU.exe
>>>

Gordon Tyler (doxxx) wrote :

I'm not certain whether the method used by bzr to invoke the merge tool will actually search that registry key.

Gordon Tyler (doxxx) wrote :

Oh I see... That makes things much simpler.

Gordon Tyler (doxxx) wrote :

Does get_app_path work for executables that would be found in the PATH? If so, I could use that as a replacement for my own PATH searching code.

Alexander Belchenko (bialix) wrote :

I think the following change should make check_availability to return True:

=== modified file 'bzrlib/mergetools.py'
--- bzrlib/mergetools.py 2011-12-19 13:23:58 +0000
+++ bzrlib/mergetools.py 2012-02-23 17:08:49 +0000
@@ -30,6 +30,7 @@
     cmdline,
     osutils,
     trace,
+ win32utils,
 )
 """)

@@ -54,7 +55,11 @@
                         for s in os.getenv('PATHEXT', '').split(os.pathsep)]
             return os.path.exists(exe) and ext in path_ext
         else:
- return osutils.find_executable_on_path(exe) is not None
+ if osutils.find_executable_on_path(exe) is not None:
+ return True
+ if win32utils.get_app_path(exe) != exe:
+ return True
+ return False
     else:
         return (os.access(exe, os.X_OK)
                 or osutils.find_executable_on_path(exe) is not None)

But the real tool invoker should convert program name to its fullpath on Windows, otherwise python will be unable to launch the program, unless you will pass "shell=True" to subprocess.Popen

Alexander Belchenko (bialix) wrote :

> Does get_app_path work for executables that would be found in the PATH? If so, I could use that as a replacement for my own PATH searching code.

No, get_app_path only looking into registry.

Alexander Belchenko (bialix) wrote :

I think we need extract path searching and checking code from check_availability and re-use it in invoke() method as well.

Gordon Tyler (doxxx) on 2012-02-24
Changed in bzr:
assignee: nobody → Gordon Tyler (doxxx)
Martin Packman (gz) on 2012-02-29
no longer affects: bzr/2.6
Changed in bzr:
milestone: none → 2.6b1
status: Confirmed → In Progress
Vincent Ladeuil (vila) on 2012-03-15
Changed in bzr:
milestone: 2.6b1 → none
status: In Progress → Fix Released
Martin Packman (gz) on 2012-03-15
Changed in bzr:
milestone: none → 2.6b1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers