@thejcannon did you got any change with play around with pyenv shell <version> and python command. I don't say it same as py, but it's good to plan or investigate how this can be implemented.

@kirankotari Yeah. Some background here, I <3 pyenv and am trying to advocate for it's usage at our company. As someone pointed out, our current processes tell Windows users to install py launcher along with Python a specific version of Python.

When we "switch" to pure-pyenv solution, they'll lose the "I can just run this Python script like any other program, by double-clicking it or running foo.py directly". Not a showstopper, but I thought it'd be reeeeeealy cool if some utility registered pyenv as the "runner" for python files like the py launcher does (or py launcher is pyenv aware).

For the time being, we'll just educate people on how pyenv works, and tell them they'll need to python <script_name>.py

@thejcannon got it. I will look into it.

I know it's been several months, were you able to make any headway?

I actually decided to spend a little time looking into this. I think the double-click launcher semantics might be trivial!

First, a simple batch file to add the right registry keys tells Windows to associate .py files with the shim (and add an icon)

reg add "HKCR\.py" /t REG_SZ /d Python.Pyenv
reg add "HKCR\Python.Pyenv" /t REG_SZ /d "Python Source File"
reg add "HKCR\Python.Pyenv\shell\open\command" /t REG_SZ /d "\"%USERPROFILE%\\.pyenv\\pyenv-win\\shims\\python.bat\" \"%%1\""
reg add "HKCR\Python.Pyenv\DefaultIcon" /t REG_SZ /d "<path-to-ico>"

And then double-clicking or calling .py files on the cmd-line should "just work".
(the only missing piece of parity is py on the cmd-line, but that's captured in #164)

... I might make a PR if you don't mind shepherding it along.

(Oh and you might need to refresh the icon cache: https://www.winhelponline.com/blog/refresh-icon-cache-windows-7-quickly/)

#198 led me to PEP 514, which py supports. How would you feel if pyenv-win:

• Set all the registry keys on each pyenv install for the specific installation (seems very doable)
• Also came with a pre-built py (with permission from the PSF).
• The registry entry for file association uses py (the PR associated with this bug, but pointing to py instead of python)

Then we'd have all the following:

• Full py cmd-line support, including specifying versions (E.g. py -3.6 would use the pyenv 3.6 installation if it existed)
• File association support (mostly from this PR, but still)
• Shebang handling as well

I honestly think if we had that pyenv-win would be the one true way to install/manage python versions on windows.

I sniffed around py's code this weekend (link) and it only looks at the PythonCore registry entries. So if we wanted it to work we'd have to fork it, tell it to look at pyenv's registry entries, and then ship the compiled code.

I don't think that's an awful idea (aside from requiring a compiler).

What needs doing here beyond just extending the registry checks to a few extra keys and ensuring someone/CI actually builds the modified py.exe?