dom/bindings/codegen/run.py: No module named Configuration

[IngwiePhoenix]

I am following the build instructions as given in README with these slight changes:

• Most of the dependencies where installed through Chocolatey.
• Because of a previous error during build, I was prompted to install Python through the Microsoft store again whilst having installed both 2.7 and 3.8 through choco before already.
• GStreamer is located at C:\gstreamer.
• virtualenv is installed through both python2 and python3 - both via Chocolatey.

During compilation (mach build --release), I get this:

error: failed to run custom build command for `script v0.0.1 (C:\Users\ingwi\work\servo\components\script)`

Caused by:
  process didn't exit successfully: `C:\Users\ingwi\work\servo\target\release\build\script-be594ff7cfff391a\build-script-build` (exit code: 1)
--- stderr
Traceback (most recent call last):
  File "dom/bindings/codegen/run.py", line 119, in <module>
  File "dom/bindings/codegen/run.py", line 20, in main
ImportError: No module named Configuration

Platform: Windows 10 1909
CPU, GPU, RAM: R9 3900X, 2080 TI, 32GB

Temporarily switching to WSL to use find . -name "run.py" would indeed show me the required file:

PS C:\Users\ingwi\work\servo> wsl
Welcome to fish, the friendly interactive shell
ingwie@bigboi /m/c/U/i/w/servo> find . -name "run.py"
./.servo/msvc-dependencies/moztools/3.2/python/Lib/idlelib/run.py
./components/script/dom/bindings/codegen/run.py
./python/_virtualenv2.7/Lib/site-packages/flake8/run.py
./tests/wpt/run.py
./tests/wpt/web-platform-tests/tools/wpt/run.py

So what am I missing here? Mind you, I have zero experience with Python. I could also be misunderstanding something here.

[jdm]

WSL is not a supported build configuration. We support building servo from windows command prompts only and can't provide support for an untested configuration.

[IngwiePhoenix]

Temporarily switching to WSL to use find . -name "run.py"

I am not building under WSL - I was merely using it as a way to access the find command.

[jdm]

The Configuration module shoukd be present in components/script/dom/bindings/codegen. Does git status show anything interesting?

[IngwiePhoenix]

No, not really.

C:\Users\ingwi\work\servo>git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

[IngwiePhoenix]

The module is, in fact, present.

C:\Users\ingwi\work\servo>dir components\script\dom\bindings\codegen
 Datenträger in Laufwerk C: ist Windows HD
 Volumeseriennummer: 22DC-E964

 Verzeichnis von C:\Users\ingwi\work\servo\components\script\dom\bindings\codegen

04.05.2020  13:02    <DIR>          .
04.05.2020  13:02    <DIR>          ..
04.05.2020  13:02                82 api.html.template
04.05.2020  13:02             1.156 apis.html.template
04.05.2020  13:02             3.037 Bindings.conf
04.05.2020  13:02           314.068 CodegenRust.py
04.05.2020  13:02            19.198 Configuration.py
04.05.2020  13:02                50 interface.html.template
04.05.2020  14:04    <DIR>          parser
04.05.2020  13:02    <DIR>          ply
04.05.2020  13:02                30 property.html.template
04.05.2020  13:02             4.180 run.py
               8 Datei(en),        341.801 Bytes
               4 Verzeichnis(se), 64.446.631.936 Bytes frei

[jdm]

I wonder if run.py is running under python3 and somehow we haven't tested that? What happens if you set the PYTHON environment variable to point to the 2.7 python executable?

[jdm]

The code that chooses which python for run.py lives in https://github.com/servo/servo/blob/master/components/script/build.rs#L67-L89.

[IngwiePhoenix]

I actually have both installed, as the instructions said I should:

C:\Users\ingwi\work\servo>py -0p
Installed Pythons found by py Launcher for Windows
 -3.8-64        C:\Python38\python.exe *
 -2.7-64        C:\Python27\python.exe

Also:

C:\Users\ingwi\work\servo>set | grep PYTHON
PYTHON2=C:\Python27\python.exe
PYTHON3=C:\Python38\python.exe

Those are set as well as the instructions said I should. Haven't tried just setting PYTHON instead and pointing that to Python 2. I'll give that a try.

Is there a way to get the execution command, or just more information in the trace and error message about invocation and used version?

[IngwiePhoenix]

Setting PYTHON = %PYTHON2% immediately had the script task pass. So, yes, we can assume that Python 3 was used instead of Python 2.

Suggestion: Make this an additional step specified in README.md to also set this environment variable to the same value as PYTHON2, as this makes sure Python 2 is used in this specific step.

[jdm]

A better short-term fix (besides fixing #26412) would be to modify that build.rs to use the PYTHON2 variable instead. It's more explicit and shouldn't require updating any documentation.