Prefer py launcher to suffixed Pythons found on PATH on Windows

[chrahunt]

Migrated from #233 (comment).

How would this feature be useful?

Give a more consistent experience by delegating to the system-managed Python on Windows.

In my specific case it would make using nox in GitHub Actions easier since it would not resolve to C:\ProgramData\Chocolatey\bin\python2.7.exe instead of the py launcher.

Describe the solution you'd like

On Windows, we should search for and prefer to invoke a py launcher for the requested version of Python before searching PATH for version-suffixed Python executables. The latter is uncommon on Windows and may resolve to MinGW or Cygwin-packaged versions which are less likely to be the target Pythons.

Describe alternatives you've considered

• Removing the undesired Python executables worked for me because it's a CI environment, so long-term impact
• for a general user they may manually edit their PATH

[dhermes]

@theacodes May be worth labeling this as Good first issue? I think (but not sure) that this is just swapping the order of an if statement in the one-resolver-to-rule-them-all function.

[vaneseltine]

As someone who has been poking around looking for place to be useful, I haven't touched this issue because I don't have confidence that a change isn't going to break someone else's workflow. It's a simple change in the code, but I'd defer to someone with a better knowledge of the various Windows combinations of virtual environments and anaconda, chocolately, and/or the py launcher. See, for example, the discussions in #231.

And tox isn't a useful point of reference (which it sometimes is) for a quick fix. They follow PEP 514 and hit the Windows registry. (See https://github.com/tox-dev/tox/tree/master/src/tox/interpreters/windows.) Switching to following PEP 514 seems like the better plan overall, to be honest.

[theacodes]

We do use PEP 514 by virtue of using the Python launcher. We're just not doing it in the right order right now.

…

On Thu, Sep 26, 2019 at 6:30 AM Matt VanEseltine ***@***.***> wrote: As someone who has been poking around looking for place to be useful, I haven't touched this issue because I don't have confidence that a change isn't going to break someone else's workflow. It's a simple change in the code, but I'd defer to someone with a better knowledge of the various Windows combinations of virtual environments and anaconda, chocolately, and/or the py launcher. Cf., for example, #231 <#231> And tox isn't a useful point of reference (which it sometimes is) for a quick fix. They follow PEP 514 and hit the Windows registry. (See https://github.com/tox-dev/tox/tree/master/src/tox/interpreters/windows.) Switching to following PEP 514 seems like the better plan overall, to be honest. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#250>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAB5I46LRRUHE5PA4UL3S53QLS2PPANCNFSM4IYFDWHA> .

[omry]

I think that all those heuristics are good and nice until there is some scenario where they fail. there would ideally be a way to directly specify which Python interpreter to use per version.

That way should be optional and only needed in the rare case the heuristic way is failing.

[dhermes]

It's already (mostly) possible to do that by putting a binary on your PATH

[omry]

This is not great for a couple of reasons:

1. It's not direct and not obvious which python would get picked up without actually running nox (and currently it does not print clearly which Python is being used for each session).
2. The heuristics will get in the way. This is exactly what this task title is talking about: If I wanted to have my python2.7 preferred after this issue is addressed putting it in the path will not work anymore.

[crwilcox]

@omry The issue with specifying it as a specific path is that isn't portable. If you and I are on the same project with the same nox file, we may have different configurations. Do I misunderstand your suggestion?

[omry]

@crwilcox:
My suggestion on #233 was to not put this into noxfile.py but to support an environment variable that would change force a specific Python interpreter to be used for a given version.
This would be portable.
something like:

NOX_PYTHON_OVERRIDE_PY27=c:/python2/bin/python.exe

For me, the problem I am trying to solve is specific to running in CI environment. I can easily change the environment variables there.
99% of the users should never need to worry about this.

[omry]

Please don't let the lack of consensus around my suggestion stop progress on this issue.
There are multiple ways to skin this cat, an in fact what I am proposing is just a final escape hatch for this class of problems. Nox should still strive to work out of the box for the most common setups.

[cs01]

IIUC the main goal of this issue is to use more "canonical" python installations first before searching around for others. The implementation would be to use the py.exe launcher. This would (very likely) solve the Windows side of #233, so I am +1 on this.