kdeldycke/meta-package-manager

`mpm` cannot find Python on Windows because of Microsoft's dummy placeholders

debakarr opened this issue · 8 comments

What happened?

I am using the following version of mpm:

$ mpm --version
mpm, version 5.11.0

When I run mpm manager I got the following output:

$ mpm managers
error:   Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.
╭────────────┬────────────────────┬───────────┬───────────────────────────────────────────────────────────────────────────┬────────────┬───────────╮
│ Manager ID │ Name               │ Supported │ CLI                                                                       │ Executable │ Version   │
├────────────┼────────────────────┼───────────┼───────────────────────────────────────────────────────────────────────────┼────────────┼───────────┤
│ cargo      │ Rust's cargo       │ ✓         │ ✓ C:\Users\debakarr\.cargo\bin\cargo.EXE                                  │ ✓          │ ✓ 1.66.1  │
│ choco      │ Chocolatey         │ ✓         │ ✓ C:\ProgramData\chocolatey\bin\choco.EXE                                 │ ✓          │ ✓ 0.10.15 │
│ composer   │ PHP's Composer     │ ✓         │ ✘ composer not found                                                      │            │           │
│ gem        │ Ruby Gems          │ ✓         │ ✘ gem not found                                                           │            │           │
│ npm        │ Node's npm         │ ✓         │ ✓ C:\Program Files\nodejs\npm.CMD                                         │ ✓          │ ✓ 8.19.2  │
│ pip        │ Pip                │ ✓         │ ✓ C:\Users\debakarr\AppData\Local\Microsoft\WindowsApps\python3.EXE       │ ✓          │ ✘         │
│ pipx       │ Pipx               │ ✓         │ ✓ c:\users\debakarr\appdata\roaming\python\python38\scripts\pipx.EXE      │ ✓          │ ✓ 1.1.0   │
│ scoop      │ Scoop              │ ✓         │ ✘ scoop not found                                                         │            │           │
│ steamcmd   │ Valve Steam        │ ✓         │ ✘ steamcmd not found                                                      │            │           │
│ vscode     │ Visual Studio Code │ ✓         │ ✓ C:\Users\debakarr\AppData\Local\Programs\Microsoft VS Code\bin\code.CMD │ ✓          │ ✓ 1.75.0  │
│ yarn       │ Node's yarn        │ ✓         │ ✘ yarn not found                                                          │            │           │
╰────────────┴────────────────────┴───────────┴───────────────────────────────────────────────────────────────────────────┴────────────┴───────────╯

Although I have python installed in C:\Python310\python.exe

Is there any way to set the cli_search_path through the mpm config file?

List package managers

No response

Meta Package Manager version

No response

Meta Package Manager configuration

No response

Thanks @Dibakarroy1997 for the bug report. What is the output in DEBUG mode? I.e. can you provide me with the results of mpm --verbosity DEBUG --pip managers?

@kdeldycke sure:

$ mpm --verbosity DEBUG --pip managers
debug: Verbosity set to DEBUG.
debug: Load configuration matching C:\Users\debakarr\AppData\Roaming\mpm\*.{toml,yaml,yml,json,ini,xml}
debug: Pattern is not an URL.
debug: Search local file system.
debug: Configuration file found at C:\Users\debakarr\AppData\Roaming\mpm\config.toml
debug: Parse configuration as TOML...
debug: Loaded configuration: {}
debug: New defaults: {}
debug: mpm, version 5.11.0
debug: {'username': '-', 'guid': 'bed95ad8aecc186f94708ffe3698ae4', 'hostname': '-', 'hostfqdn': '-', 'uname': {'system': 'Windows', 'node': '-', 'release': '10', 'version': '10.0.22000', 'machine': 'AMD64', 'processor': 'Intel64 Family 6 Model 140 Stepping 1, GenuineIntel'}, 'linux_dist_name': '', 'linux_dist_version': '', 'cpu_count': 8, 'fs_encoding': 'utf-8', 'ulimit_soft': 0, 'ulimit_hard': 0, 'cwd': '-', 'umask': '0o0', 'python': {'argv': '-', 'bin': '-', 'version': '3.8.3 (tags/v3.8.3:6f8c832, May 13 2020, 22:37:02) [MSC v.1924 64 bit (AMD64)]', 'compiler': 'MSC v.1924 64 bit (AMD64)', 'build_date': 'May 13 2020 22:37:02', 'version_info': [3, 8, 3, 'final', 0], 'features': {'openssl': 'OpenSSL 1.1.1f  31 Mar 2020', 'expat': 'expat_2.2.8', 'sqlite': '3.31.1', 'tkinter': '8.6', 'zlib': '1.2.11', 'unicode_wide': True, 'readline': False, '64bit': True, 'ipv6': True, 'threading': True, 'urandom': True}}, 'time_utc': '2023-02-12 13:43:15.612380', 'time_utc_offset': 5.5, '_eco_version': '1.0.1'}
debug: Initial population of user-selected managers: pip
debug: CLI found at C:\Users\debakarr\AppData\Local\Microsoft\WindowsApps\python3.EXE
debug: ► C:\Users\debakarr\AppData\Local\Microsoft\WindowsApps\python3.EXE -m pip --no-color --version
error:   Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.
╭────────────┬──────┬───────────┬─────────────────────────────────────────────────────────────────────┬────────────┬─────────╮
│ Manager ID │ Name │ Supported │ CLI                                                                 │ Executable │ Version │
├────────────┼──────┼───────────┼─────────────────────────────────────────────────────────────────────┼────────────┼─────────┤
│ pip        │ Pip  │ ✓         │ ✓ C:\Users\debakarr\AppData\Local\Microsoft\WindowsApps\python3.EXE │ ✓          │ ✘       │
╰────────────┴──────┴───────────┴─────────────────────────────────────────────────────────────────────┴────────────┴─────────╯

I would not call it a bug exactly but I guess it's lack of configuration. User can have several versions of python installed in the system (python3.8 or python3.9 or python3.10 etc) and again we can have several virtual environment. Also, the current logic only searches for python3 executable. And windows has a default empty python3 executable at C:\Users\debakarr\AppData\Local\Microsoft\WindowsApps which just points to Microsoft Store if python is not installed from there (below image has 0kb python3.exe file)

image

1 solution I found is to either rename or make a duplicate executable with python3 name and make sure that path of the executable is at the front of PATH environment variable.

image

I saw that cli_search_path is getting prepended to PATH before we do cli search.

https://github.com/kdeldycke/meta-package-manager/blob/main/meta_package_manager/base.py#L382-L384

If we can get a way to configure cli_name and cli_search_path then it would be great.

Thanks @Dibakarroy1997 for the detailed explanation! I'm not an everyday user of Windows so I often lacks the expertise to make the best decision.

I just realised, thanks to your screenshots, that Microsoft puts on the filesystem a couple of placeholders that are 0 KB files for popular tools, frameworks, languages and CLIs. These placeholders are referenced in the environment's PATH, and upon execution, hints at installing them via the Microsoft App Store. This message is captured by mpm in the logs:

error:   Python was not found; run without arguments to install from the Microsoft Store, or disable this shortcut from Settings > Manage App Execution Aliases.

Your workaround of updating the PATH environment variable to prioritize the right executable is spot-on and the way to go.

Now I like your idea of making it easier for the user to change that via configuration of mpm itself. I'll create a new issue to track that feature request.

Another thing we can do is alter the way mpm search for each package manager CLI to have it find all versions and variants available on the system. This might open the way to implement #629, which is a feature requests to manage multiple versions of the same package manager.

Setting of search path in config file is tracked by: #945

The upcoming mpm v5.12.0 will now skip empty files in CLI search results to skip Microsoft's dummy placeholders on Windows.

I'll probably release this version in a couple of days.

Thank you @kdeldycke.

I just tagged mpm v5.12.0 the package will be available in the next couple of minutes on PyPi, and the binaries on the GitHub release too.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.