-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hardcoded Python executable path depends upon system Python being installed #114
Comments
As found in #115, the current best solution is not to symlink Salt's bundled Python. Instead, install Python on the system (so you will have two Python installations). |
@vps-eric This is done for salt-pip by design. There are two ways you can install python packages that have C extensions. One is to compile the extension against the relenv's libraries. The other way is to compile c extensions against the system's libraries. We decided make the default install against the system's libraries because it tends to be easier for users. In this case you need a system python installed so that relenv can figure out the compiler options to use to compile against your system's libraries. If you want to install using relenv's libraries you need should set the |
@dwoz Do you have some docs on |
@dwoz I appreciate the clarification, thank you. As someone who's brand new to this relenv idea, what is simplified for users by installing against system libraries? My impression is that I'd need to install dependencies on the system (finding system pip and then defining it in |
If we were to default to using relenv's dependencies it would mean you would have to build any non-python dependencies from source and install them into relenv's lib directory. That means you'd be compiling libssh2 and libgit2 to be able to install pygit2, for example. Another case would be having to build openldap to install python-ldap. Versus, by defaulting to the system packages you are able to install those dependencies from your OS with yum, apt, ect. |
Given that relying on system Python is required, I propose that the hardcoded path is still removed and that it uses PATH instead, or gives a useful error message for the user. |
I agree that pulling the 'system' python from the path is a better way forward. I'm also going to provide pip some sane defaults for when no system python is present. |
Fixed in 0.12.0 |
Certainly some of the libraries you compile against have to be relenv's. Because those are the libraries it's going to run with and may not be ABI-compatible with the system ones. The version of Python, for example. |
get_config_vars_wrapper(...)
runs Python as a subprocess (more explanation on why this is necessary would be great). The path to Python to run in the subprocess is hard coded to/usr/bin/python3
, which is not always installed and would require either a symlink to Salt'ssalt-pip
or a system Python installation.To reproduce, spin up Almalinux 8.7 (I do so in Vagrant on QEMU) and manually install the Salt minion, confirming there is no Python installed on the system. Then, log in and execute:
Exception
This issue can be bypassed by:
The text was updated successfully, but these errors were encountered: