Description
What's the problem this feature will solve?
Use case (build portable python packages to be usable on other machines with no internet access):
- Use python embedded for Windows (https://www.python.org/ftp/python/3.12.8/python-3.12.8-embed-amd64.zip)
- Unzip python embedded e.g. C:\mypythonapp\python.exe and enable main in the pth file and install pip via get-pip.py.
- Install packages that create exes in /Scripts e.g. python.exe -m pip install MapProxy
- Move the python app folder e.g. C:\mypythonapp to D:\mypythonapp
There are exes e.g. mapproxy-util.exe pip installs to Scripts which have the original full path to python.exe hardcoded in the exe binary. This allows them to only work from that path and prevent ability to make portable.
Describe the solution you'd like
Some solution to make the exes in Scripts portable with pip install. Perhaps a flag to create exes with relative paths to python.exe.
Alternative Solutions
The work around I implemented was to extract the script the exe runs (used a hex editor to view) and used as a python.exe script file argument. This is problematic though, for example in the case of MapProxy's mapproxy-util.exe, the code automatically appends ".exe" to the file path e.g. https://github.com/mapproxy/mapproxy/blob/master/mapproxy/util/ext/serving.py#L386C12-L386C20. As a solution I named the python script mapproxy-util.py.exe to "trick" it. I also deleted all the exe files pip installed in Scripts since they are not usable outside of the original directory.
Additional context
I asked chat GPT how this can be addressed and it recommended a few things I have not tried such as use pyinstaller or shiv. I haven't tried these yet so am not sure if they work as an alternative way to create a portable app package. Ideally I'd like to just address the root problem of having hard coded paths in the exe files in Scripts.
Code of Conduct
- I agree to follow the PSF Code of Conduct.