Creating a common cross-platform "Python installation finder" library?

[ncoghlan]

This idea will presumably be deemed out-of-scope for pep514tools itself, but I figure it's as good a place as any to start an initial discussion, since searching the Windows registry is the most complex platform-specific discovery option.

In a recent python-ideas discussion, @GadgetSteve suggested it might be desirable for pip to directly support Python Launcher for Windows style version selection arguments (pip -2 install, pip -3 install, etc).

I then mentioned that the --python option in pipenv already worked much like that, and @pfmoore mentioned this project as being relevant to the Windows case.

Looking at the pipenv code, that currently relies primarily on PATH scanning: https://github.com/kennethreitz/pipenv/blob/d320bc4b1e/pipenv/cli.py#L348

It then also has some native support for the pyenv environment manager (although that part may not work on Windows): https://github.com/kennethreitz/pipenv/blob/d320bc4b1e/pipenv/cli.py#L394

(If we decide to move the discussion away from here, then PyPA's "python packaging problems" would likely be the best place - this becomes a packaging problem by virtue of the fact that packaging tools need to figure out which environment to operate on when they're not just relying on sys.executable)

[techalchemy]

Hey @zooba just to follow on from @ncoghlan I have created https://github.com/techalchemy/pythonfinder which has this library vendored, but currently runs into a few issues on windows, should I pr them over to here or, what would be the best way to handle this?

/cc @pfmoore who I know has an interest in this

[zooba]

@techalchemy PRs over here would be great. Happy to merge changes.

[techalchemy]

Just as a follow up since I know I've spoken to all of you independently and there is simultaneous re-work being done on this tooling for both windows and linux, is there a centralized place where it would make sense to focus the higher level discussions about the kind of consumption-level API design? Or is it safe to assume that whatever the implementation details are, the final APIs will be compatible?

/cc @brettcannon

[zooba]

It's really up to the people who are planning to write the other implementations. I don't have any intention on trying to standardize the specific API here (though the metadata, structure, and extensibility points in PEP 514 are already standardized, so I'd hope a shared API is at least compatible with those).

I suspect the first step is to define the way that PEP 514 can be cross-platform, such that interpreters can provide equivalent metadata about themselves. Without that, it'll all be pretty ad hoc.

[brettcannon]

The other question is whether this desired API is meant to be consumed by executing a shell command or via some library? As of right now, other than potentially supporting py -0 there are no concrete plans on my side of having an API that doesn't extend beyond something in Rust that's simply necessary to implement the app.

And all of this is predicated on the idea that I actually finish the Python launcher for UNIX and it actually goes somewhere. 😉