_PIP_INSTALL_ARGS="--prefix=/usr" assumes the in-use pip3.10 is installed under /usr

[jinnatar]

Description of Issue/Question

Line in question:

salt-bootstrap/bootstrap-salt.sh

Line 276 in 725d18f

_PIP_INSTALL_ARGS="--prefix=/usr"

This assumes that in all scenarios the currently resolved py3.10 environment is installed under /usr. This is not always true, for example the official python:3.10-alpine image has it under /usr/local. This crashes and burns late in setup when setuptools is upgraded which causes the preinstalled setuptools in /usr/local to be uninstalled and replaced by a newer one in /usr. Then mysteriously once we get to building the salt wheel, setuptools is nowhere to be found becqause the env in use is still in /usr/local which is now missing setuptools due to the "upgrade".

Setup

FROM python:3.10-alpine
ARG SALT_VERSION=v3007.1
RUN apk update && apk add --no-cache git patch
RUN python3 -c 'import urllib.request; print(urllib.request.urlopen("https://bootstrap.saltproject.io").read().decode("ascii"))' > bootstrap-salt.sh
#ADD prefix.patch .
#RUN patch bootstrap-salt.sh < prefix.patch
RUN sh bootstrap-salt.sh -MN -X git ${SALT_VERSION}

Steps to Reproduce Issue

1. Try to build the above container image.
2. With a small patch the issue is resolved (but fails further down with alpine post_install):

276c276
< _PIP_INSTALL_ARGS="--prefix=/usr"
---
> _PIP_INSTALL_ARGS=""

Versions and Systems

(salt --versions-report, bootstrap-salt.sh -v, system type and version,
cloud/VM provider as appropriate.)
./bootstrap-salt.sh -- Version 2024.07.23

[jinnatar]

.. I'm not sure what the prefix is intended to accomplish. In all situations I can think of, whichever pip3.10 is being run should know it's system path and be capable of upgrading and installing into the correct 3.10 env. This is becoming increasingly important since Salt is still stuck on py3.10 whereas any reasonable base image is at py3.12, which means that using the system default py3 isn't an option anymore.