`git-sequence-editor` invoked with wrong path on Windows about git-cola

[sthalik]

Let me know if copying git-cola-sequence-editor into that location makes a difference.

It works and it's a good workaround. Thank you.

[davvid]

I've committed a small tweak that I believe should have resolved this issue. Let me know if you're able to test this out from source or from the CI-built installers and if it's not working I'll try and fix it before the next release. Thanks for the heads-up.

[sthalik]

It doesn't work when invoked using the git-cola.exe wrapper. The extensionless path doesn't exist. Only the .exe wrapper does.

C:\Python3.12\python.exe: can't open file 'C:\\Python3.12\\Scripts\\git-cola-sequence-editor': [Errno 2] No such file or directory
error: There was a problem with the editor '/C/Python3.12/python.exe /c/Python3.12/Scripts/git-cola-sequence-editor'.

There's also the scenario where bin/git-cola is copied as git-cola.py, but the script doesn't reside inside the Python's installation directory in order to survive Python upgrades, then is invoked using pythonw. It's then looking for C:\\bin\\git-cola-sequence-editor. It wouldn't hurt to install the bin/ wrappers to avoid the necessity of that scenario.

[davvid]

Darn, I thought those changes would do it. I'll dust off the Windows VM and try to get to the bottom of this soon.

Just so that I'm following along exactly -- can you please share the install commands that you used to install git-cola into that location? Was it a simple pip install . from inside a clone of the repo?

[sthalik]

Yes. The procedure is:

> pip install .
> python bin\git-cola

[davvid]

Thanks for sharing the exact steps you took -- that helped me narrow this down. The bug ended up being something really simple. Instead of using the sibling_exe variable I was assigning from the sibling variable.

Please give this a try again. I can at least verify that I was able to reproduce the bug with those steps and then they were fixed in my testing after making this change.

[sthalik]

I can confirm it works through git-cola.exe. However, it doesn't work when launching through bin/git-cola.

[davvid]

Ah, that's interesting. Interestingly, I'm unable to launch ./bin/git-cola that way because the Windows python3.11 installer doesn't seem to provide a command called python3 so the shebang #! lines don't end up working out.

I can use python ./bin/git-cola however, and that works for both cola and the rebase editor. Do you have the same (or a different) python3 in your $PATH?

I'm using a Git for Windows Bash shell and the Python 3.11.4 installer from python.org in a Windows 11 Pro virtual machine.

[sthalik]

Here's my setup:

%USERPROFILE%\opt is in Path. Then, bin/git-cola copied to ~/opt/git-cola.py. It's not invoked by git cola because .py isn't in ComSpec. Thus, for git-cola.cmd and git-dag.cmd, respectively:

C:\Users\sthalik>type opt\git-cola.cmd
@setlocal
@set path=C:\Program Files\Git\cmd;%USERPROFILE%\opt;c:\Python3\Scripts;c:\python3;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
@start pythonw "%USERPROFILE%/opt/git-cola.py" %*

C:\Users\sthalik>

After all this needless circus is complete, I can type:

~/dev/myrepo $ git cola

and it launches and detaches from the terminal.

This works for both git-scm.com Git and MSYS2 Git at the same time.

Note that from MSYS2/Cygwin you can:

~/opt $ ./git-cola.cmd 

which enables it to work.

Fortunately you didn't see msvc.cmd or mingw64.cmd....

[davvid]

That's super helpful. Here's some pointers in case they help.

pythonw "%USERPROFILE%/opt/git-cola.py"

The cola/resources.py module attempts to find things relative to the script that started the current python program (in this case, .../opt/git-cola.py).

That code is here:

git-cola/cola/resources.py

Line 51 in e7edb2b

if compat.WIN32:

This suggests that if you copy bin/git-cola-sequence-editor to %USERPROFILE%/opt/git-cola-sequence-editor then it might start working because the "find sibling" behavior will find the file there and it'll be able to launch the editor from that location.

Another alternative would be to change git-cola.cmd so that it launches the bin/git-cola script using a full path into a clone of the repo rather than running a copy of it from ~/opt/. That should make the "find sibling" behavior find the ./bin/git-cola-sequence-editor command since the main entry point will be the script from inside the repo, which is sibling to that script.

I think what's confusing the logic right now is that the ~/opt/git-cola.py main entry script isn't located in the same directory as its companion git-cola-sequence-editor script.

Another detail is that we don't actually execute the command ourselves. We just set an environment variable with /path/to/python.exe /path/to/git-cola-sequence-editor in it and git rebase uses that value to execute the editor. That's why this is a little more finicky than usual -- the code has to make some assumptions about how things are installed and laid out on the file system.

Let me know if copying git-cola-sequence-editor into that location makes a difference.