Mason uses my system's python bin instead of the one specified by python3_host_prog

[serhez]

Problem description

Mason is using my system's python (and therefore pip) to install python packages required for my installed tools. I use a conda environment to separate my nvim tools from the rest of my system, but mason is breaking this separation. Is this a bug or a feature? If a feature, could we have a python_path config option which defaults to the python path defined by python3_host_prog or the system's python path but which could also be set to some other binary (e.g., one in a venv)?

Thanks!

Neovim version (>= 0.7)

NVIM v0.8.0-dev-1121-g10196f1b4-dirty
Build type: Release
LuaJIT 2.1.0-beta3

Operating system/version

MacOS; Darwin Kernel Version 21.6.0; arm64

I've recently downloaded the latest plugin version of mason.nvim

• Yes

Actual behavior

Uses system's python and pip.

Expected behavior

To use the python and pip binaries as specified by python3_host_prog.

Healthcheck output

mason: require("mason.health").check()
========================================================================
## mason.nvim report
  - OK: neovim version >= 0.7.0
  - OK: **Go**: `go version go1.18.3 darwin/arm64`
  - WARNING: **cargo**: unsupported version `cargo 1.59.0`. Some cargo installations require Rust >= 1.60.0.
  - OK: **luarocks**: `/opt/homebrew/bin/luarocks 3.9.1`
  - OK: **Ruby**: `ruby 2.6.8p205 (2021-07-07 revision 67951) [universal.arm64e-darwin21]`
  - OK: **RubyGem**: `3.0.3.1`
  - WARNING: **Composer**: not available
  - WARNING: **PHP**: not available
  - OK: **npm**: `8.15.0`
  - OK: **node**: `v16.17.1`
  - OK: **python3**: `Python 3.9.13`
  - OK: **pip3**: `pip 22.1.2 from /opt/homebrew/Caskroom/miniconda/base/lib/python3.9/site-packages/pip (python 3.9)`
  - WARNING: **javac**: not available
  - WARNING: **java**: not available
  - WARNING: **julia**: not available
  - OK: **wget**: `GNU Wget 1.21.3 built on darwin21.3.0.`
  - OK: **curl**: `curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1`
  - OK: **gzip**: `Apple gzip 353.100.22`
  - OK: **tar**: `bsdtar 3.5.1 - libarchive 3.5.1 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.8 `
  - OK: **bash**: `GNU bash, version 5.1.16(1)-release (aarch64-apple-darwin21.1.0)`
  - OK: **sh**: `Ok`
  - WARNING: **python3_host_prog**: not available
  - OK: GitHub API rate limit. Used: 15. Remaining: 4985. Limit: 5000. Reset: Mon Oct  3 16:49:37 2022.

Screenshots

No response

[williamboman]

Hello! Mason actually tries to use g:python3_host_prog first, if it's defined (and if the python binary it's referring to supports native venv [python >= 3.3]). The checkhealth output suggests there's a problem with python3_host_prog, are you certain it's referring to a valid python3 binary?

[serhez]

Hello @williamboman, thank you for the reply. I am pretty certain that python3_host_prog is referring to a valid bin, as this is shown in neovim's general checkhealth:

provider: health#provider#check
========================================================================

## Python 3 provider (optional)
  - INFO: Using: g:python3_host_prog = "~/.envs/nvim/bin/python"
  - INFO: Executable: /Users/<me>/.envs/nvim/bin/python
  - INFO: Python version: 3.10.4
  - INFO: pynvim version: 0.4.3
  - OK: Latest pynvim is installed.

## Python virtualenv
  - OK: no $VIRTUAL_ENV

[williamboman]

Ah, the ~ will not be expanded by the APIs Mason use to spawn processes (libuv).

[williamboman]

#519 should hopefully fix this

[serhez]

Thanks man, appreciate the fix 👍🏻