Running ORT on Windows tries to run scancode.bat, which might not exist

[cgz42]

When installing scancode-toolkit via pip (python -m install scancode-toolkit), no scancode.bat file is created. As a consequence the scancode invocation from ORT fails, as the usage of 'scancode.bat' is hard-coded on Windows.

Tested with:

• Ort 4.0.0
• scancode-toolkit 32.0.8
• python 3.9.16

When I add a scancode.bat next to the scancode executable, simply forwarding all the command line arguments, ORT scan with scancode works.

[sschuberth]

python -m install scancode-toolkit

I guess this should say "python -m pip install scancode-toolkit"? Anyway, I just tried, and it seems ScanCode is now using an .exe on Windows which is located e.g. at C:\Users\Sebastian\AppData\Roaming\Python\Python38\Scripts\scancode.exe.

Out of curiosity, @pombredanne do you recall when (in which version) ScanCode switched from .bat to .exe on Windows?

[cgz42]

Yes, you are right. I forgot the install command in the pip command line.

The scancode.bat still exists in the scancode tarballs you can download from the scancode repository. It actually wraps the invocation of scancode.exe. When the batch file is called the first time, its runs configure.bat to create the scancode virtualenv and creates scancode.exe.

[sschuberth]

It actually wraps the invocation of scancode.exe.

So, would you agree that simply calling scancode.exe instead of scancode.bat from ORT should fix the issue?

[cgz42]

This will break ORT for developers, who used the scancode tarball from the repo, because there is no scancode.exe. scancode.bat creates scancode.exe. On the other hand you can argue, that scancode-toolkit should have been configured once before calling ORT.

Safer options could be:

• Check which file exists: if scancode.bat exists, use this one, otherwise call scancode.exe
• Remove extension completely and simply call 'scancode'. This works on the command line and would call scancode.bat or scancode.exe - whatever is first in the PATH. But: I am not sure, if this works the same way when called from kotlin.

[sschuberth]

But: I am not sure, if this works the same way when called from kotlin.

Indeed that unfortunately doesn't work with Kotlin's / Java's ProcessBuilder, so I'll go for your first proposal.

[malteharms]

Are there plans to solve this bug in the near future? I would be interested in the result