[SERVER-42911] Rebuild mongodb by building.md and failed to build due to ModuleNotFoundError: No module named 'Cheetah' with MSVC on windows Created: 20/Aug/19 Updated: 29/Oct/23 Resolved: 03/Sep/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Build |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.15, 4.0.13, 3.4.23, 4.2.1, 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | LinGao | Assignee: | Mathew Robinson (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
VS 2017 + Windows Server 2016 + MongoDB master branch latest revision |
||
| Issue Links: |
|
||||
| Backwards Compatibility: | Fully Compatible | ||||
| Backport Requested: |
v4.2, v4.0, v3.6, v3.4
|
||||
| Sprint: | Dev Tools 2019-08-26, Dev Tools 2019-09-09 | ||||
| Participants: | |||||
| Description |
|
We tried to rebuild mongodb by building.md, after executing the python.exe buildscripts/scons.py all -j4 command, the error will always be reported as below: C:\Python\Python37\python.exe src\mongo\base\generate_error_codes.py src\mongo\base\error_codes.yml src\mongo\base\error
And we checked the 'src\mongo\base\generate_error_codes.py' file, but I don't understand why this error was reported: ModuleNotFoundError: No module named 'Cheetah' . Could you please help to take a look at this issue? Is there any configuration missing? Thanks in advance!
Note: F:\git_projects\mongodb\mongo> python --version scons: Reading SConscript files ... |
| Comments |
| Comment by Githook User [ 09/Sep/19 ] |
|
Author: {'username': 'chasinglogic', 'email': 'mathew.robinson@mongodb.com', 'name': 'Mathew Robinson'}Message: (cherry picked from commit 89b3607e30edefe76ac84052cfe411ee1fda3b95) |
| Comment by Githook User [ 09/Sep/19 ] |
|
Author: {'name': 'Mathew Robinson', 'username': 'chasinglogic', 'email': 'mathew.robinson@mongodb.com'}Message: (cherry picked from commit 89b3607e30edefe76ac84052cfe411ee1fda3b95) |
| Comment by Githook User [ 09/Sep/19 ] |
|
Author: {'username': 'chasinglogic', 'email': 'mathew.robinson@mongodb.com', 'name': 'Mathew Robinson'}Message: (cherry picked from commit 89b3607e30edefe76ac84052cfe411ee1fda3b95) |
| Comment by Githook User [ 09/Sep/19 ] |
|
Author: {'name': 'Mathew Robinson', 'username': 'chasinglogic', 'email': 'mathew.robinson@mongodb.com'}Message: (cherry picked from commit 89b3607e30edefe76ac84052cfe411ee1fda3b95) |
| Comment by Mathew Robinson (Inactive) [ 03/Sep/19 ] |
|
spacelg I'm going to close this ticket, if you pull in the commit from above you should no longer experience this issue. Feel free to reopen if the above commit does not resolve this for you. |
| Comment by Githook User [ 28/Aug/19 ] |
|
Author: {'email': 'mathew.robinson@mongodb.com', 'name': 'Mathew Robinson', 'username': 'chasinglogic'}Message: |
| Comment by Mathew Robinson (Inactive) [ 28/Aug/19 ] |
|
Hey spacelg, Thanks for bringing this to our attention. This is actually a weird interaction between how SCons creates subprocesses, pip with the --user flag, and how Python does module lookups. SCons does not, by design, automatically forward all parent environment variables down to subprocesses. This includes variables like %APPDATA% on WIndows which tells Python where to look for user site packages. Since you installed the requirements.txt (correctly) using the --user option it installed the packages into this user site-packages directory. This is why SCons was able to import those packages, like psutil, but when it ran python subprocesses like generate_error_codes.py they could not. I've made the change to our SConstruct to pass %APPDATA% down to subprocesses to fix this issue on Windows. If you need to build an older branch or do not want to wait for this fix to land you can work around it by running your pip install command without the --user flag. Thanks. |
| Comment by Kelsey Schubert [ 21/Aug/19 ] |
|
Hi spacelg, I've assigned this issue to the Developer Tools team to investigate — we'll look into it. Kind regards, |
| Comment by LinGao [ 21/Aug/19 ] |
|
Hi, Is there anyone looking at this issue ? Thanks, Lin |