How to instruct the Windows py.exe launcher about python installs it doesn’t find automatically?
» py -0p
-V:3.12 * C:\apps\python\python.exe
-V:2.7-32 C:\Python27\ArcGIS10.8\python.exe
I want it to also see:
C:\apps\python\python.exe
C:\ArcGIS\bin\Python\envs\arcgispro-py3\python.exe
C:\ArcGIS\DataInterop\fmepython310\python.exe
C:\FME\fmepython311\python.exe
C:\Program Files\QGIS 3.32.0\bin\python.exe
Maybe this helps: PEP 514 – Python registration in the Windows registry | peps.python.org
This is how the Python launcher finds Python installations according to this: 4. Using Python on Windows — Python 3.12.0 documentation
hmm. The Company and Tag sections seem to be most relevant. I’m not sure I want to embark on registry edits, but I know where to start now if the itch grows that strong.
You could also look into the Packaging category for some answers. I seem to recall that this topic might have been addressed there already, but also maybe it was just a tangentially related topic.
Maybe @steve.dower has some suggestions.
PEP 514 is the way to do it. If it’s just for your own machine, you can pick any Company and Tag you like - they’ll both appear in the -0p output (see the last entry in this example):
C:\> py -0p
-V:3.13 * C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.13_3.13.161.0_x64__3847v3x7pw1km\python3.13.exe
-V:3.12 C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.12_3.12.240.0_x64__3847v3x7pw1km\python3.12.exe
...
-V:ContinuumAnalytics/Anaconda39-64 C:\Users\stevdo\Miniconda3_2\python.exe
Bear in mind that the launcher will match any company if you pass py -V:tag, or the “latest” tag if you pass py -V:company/, so depending on how you decide which version you want to run, you can probably choose a scheme that’ll suit you.
(If you don’t use the -V option, it’ll only search PythonCore tags, just like the older version of the launcher that didn’t fully support PEP 514.)
ok thanks, and to be sure I’m clear: the minconda at bottom is there because you added registry key for it, right?
The Anaconda and Miniconda installers register themselves, and have done for a long time (hence why they’re registered under the old company name instead of “Anaconda”, though I’m sure they’ll update it when they notice 
)
Ah, thanks. I’ve switched to use using micromamba which, apparently, doesn’t do that.
I’m struggling with this, related to Anaconda/conda issues on Windows. Putting the conda/Anaconda issues aside for a moment:
Is the only way to register a Python environment for the Python launcher on Windows by adding keys to the Windows registry?
Is there no way to add an environment through py.ini?
The docs have a number of mentions of py.ini but don’t really define the supported sections. It seems a default version can be specified, but it must already be “registered”, it can’t be specified by path.
My primary questions are above. The rest of this is just an FYI if someone wants my specifics.
Thanks for any help and insights!
I did cobble together registry entries for the Anaconda Distribution of 3.11 I have installed that work for py -0p but I don’t think they are technically correct. I used a fresh install of Python.org 3.12 keys as a guide, but I think they are in the wrong place in the tree since I guess they should be under ContinummAnalytics some place.
> py -0p
argv0: py
version: 3.12.1
# Reading from C:\Users\rct\AppData\Local\py.ini for defaults/python
# Found python in C:\Users\rct\AppData\Local\py.ini
SearchInfo.originalCmdLine: py -0p
SearchInfo.restOfCmdLine:
SearchInfo.executablePath: (null)
SearchInfo.scriptFile: (null)
SearchInfo.executable: python.exe
SearchInfo.executableArgs: (null)
SearchInfo.company: PythonCore
SearchInfo.tag: 3.11
SearchInfo.oldStyleTag: False
SearchInfo.lowPriorityTag: True
SearchInfo.allowDefaults: True
SearchInfo.allowExecutableOverride: True
SearchInfo.windowed: False
SearchInfo.list: False
SearchInfo.listPaths: True
SearchInfo.help: False
SearchInfo.limitToCompany: (null)
-V:3.12 C:\sw\Python-org\Python312\python.exe
-V:3.11 * C:\sw\Anaconda3\python.exe
Note The first example code for reading the windows registry in PEP514, find both environments but says they aren’t executable:
c:\sw\Anaconda3\python.exe pep-514-registry-example-1.py
PythonCore\3.11 - (not executable)
PythonCore\3.12 - (not executable)
Here’s the output of the 2nd example from PEP-514
r>c:\sw\Anaconda3\python.exe pep-514-registry-example-2.py
Company: Python Software Foundation
Support: http://www.python.org/
PythonCore\3.11
Name: Python 3.11
Support: http://www.python.org/
Version: 3.1
SysVersion: 3.1
SysArchitecture: (unknown)
InstallPath: C:\sw\Anaconda3
ExecutablePath: C:\sw\Anaconda3\python.exe
WindowedExecutablePath: C:\sw\Anaconda3\python.exe
PythonCore\3.12
Name: Python 3.12
Support: http://www.python.org/
Version: 3.1
SysVersion: 3.1
SysArchitecture: (unknown)
InstallPath: C:\sw\Python-org\Python312\
ExecutablePath: C:\sw\Python-org\Python312\python.exe
WindowedExecutablePath: C:\sw\Python-org\Python312\python.exe
The second sample generates ExecutablePath for you automatically (because it’s a sample of backwards compatibility for Python 3.5 and earlier, which isn’t really applicable to what you’re doing), so I guess it’s not finding that value.
Bear in mind that InstallPath is a key and ExecutablePath is a value under that key. If you have them both as values under the parent key, it won’t work.
Showing your actual registry entries would be more helpful here than some example script output.
And yeah, sorry, PEP 514 is the only way to register a runtime. I don’t know whether py.ini is robust enough to add command-line options to py (without conflicting with python options), but if someone figures that out and contributes the code, I don’t know that we’d be totally opposed to it.
But registry keys are generally the preferred way for distros to provide their own registration - you don’t want an installer trying to modify your py.ini.
Thank you for replying so quickly.
When you say registry keys the “preferred way”, that somewhat implies there is another way. But it sounds like registry keys are the only way unless I’ve missed something?
They could provide their own py.exe that knows how to find their install, or hack your py.ini to always redirect to their executable, or overwrite an existing Python install with their own.
PEP 514 is preferred because any other ways to make it “work” are probably harmful. It’s the only way we support, but we can’t physically stop people from doing horrible things that also often work.
Thanks but I think we’re looking at this from different angles.
If a user (not someone developing/supporting a distro) has a situation where they have python installation not found by the launcher, what should they do?
If the Python installation is something installed by some sort of distro and the keys aren’t there for some reason, then I can see that possible answers are 1) uninstall/reinstall the distro (clumsy but likely effective) 2) seek support from the distro vendor 3) read PEP 514 and try to cobble together the right registry keys.
But what if the Python installation isn’t from a vendor? I haven’t tried to build from source on windows, is there part of that build/install process that would do the registration?
Those three answers are correct.
We aren’t trying to build a user-friendly DIY kit here, we’re building a developer tool. Our installer sets the keys right, and if some other developer doesn’t, then their users should be asking them to. If they won’t, you’re now the developer, and have to do developer-like tasks. Modifying the registry is it (unless someone’s written a script to help you modify it, which anyone can do - PEP 514 is pretty stable).
If you build from source you’ll run from the build directory. There’s nothing that registers your build to be run globally, because inherently it isn’t global. To get the registration, you’d build the entire installer and then install it, which is what we do when we make a release.
Thanks for your responses. I had assumed I’d be able to do more configuration of the launcher, through config files, but that’s not the case and I can understand why.
I guess any organizations that produce distros should be encouraged to make sure the process of registering keys and cleaning up out dated entries is robust. ideally, there should be some mechanism to check/re-register if necessary without having to uninstall/re-install.
I’ve found open issues at anaconda, though they haven’t gotten any attention.