Would something like this be helpful? (`python -m pip` seems to work fine after `conda install pip` after a miniconda install)
```python #!/usr/bin/env python """ Something like this as e.g site.discover (for use as ``python -m site.discover``) could be helpful for explaining and diagnosing multiple pythons and pips """
import os import re from distutils.spawn import find_executable from subprocess import check_output, STDOUT import collections
def discover(path=None, printsite=False, uniques=True): """ Find all ``python*`` and ``pip*`` executables and their version strings within ``os.environ['PATH']``
Kwargs: path (str): os.pathsep-delimited path str (defaults to ``os.environ['PATH']``) printsite (bool): call ``<python> -m site`` with each found python binary uniques (bool): print uniques according to ``os.realpath`` at the end
Returns: None """ if path is None: path = os.environ['PATH'] rgx = re.compile(r'(python|pip)-?(\d?.?\d?)$') uniques = collections.OrderedDict() for directory in path.split(os.pathsep): paths = sorted( ((match.group(0), match.group(2)) for match in (rgx.match(name) for name in os.listdir(directory)) if match), key=lambda x: x[::-1], reverse=True) print(u'# %s' % directory) for (name, ver) in paths: pathjoined = os.path.join(directory, name) binpath = find_executable(pathjoined, directory) realpath = os.path.realpath(binpath) if binpath is None: continue if os.path.exists(pathjoined): if os.path.islink(pathjoined): print(( u"%r is a symlink to %r, which doesn't exist" % (pathjoined, binpath))) # TODO: %r exists but isnt executable verstring = check_output((binpath, '-V'), stderr=STDOUT).rstrip() uniques.setdefault(realpath, collections.OrderedDict()) \ .setdefault(binpath, verstring) print(u'%-11r %-5r %r' % (name, ver, verstring)) if printsite and name.startswith('python'): sitestring = check_output((binpath, '-m', 'site')) lines = (u'> %s' % l for l in sitestring.splitlines()) for line in lines: print(line) # TODO: check_output((binpath, '-m', 'pip'))
# TODO: AND/OR (?) only print uniques at the end if uniques: print('### UNIQUES') for path in uniques: print('## %s' % path) paths = uniques.get(path) for otherpath in sorted(paths): print(otherpath) print('')
if __name__ == '__main__': discover()
On Wednesday, November 15, 2017, Steve Dower email@example.com wrote:
On 15Nov2017 0617, Nick Coghlan wrote:
On 15 November 2017 at 22:46, Michel Desmoulin <firstname.lastname@example.org mailto:email@example.com> wrote: Should I do a PEP with a summary of all the stuff we discussed ? I think a Windows-specific PEP covering adding PATH updates back to the default installer behaviour, and adding pythonX and pythonX.Y commands would be useful (and Guido would presumably delegate resolving that to Steve Dower as the Windows installer maintainer).
If you write such a PEP, please also research and write up the issues with modifying PATH on Windows (they're largely scattered throughout bugs.p.o and earlier discussions on python-dev).
Once you realise the tradeoff involved in modifying these global settings, you'll either come around to my point of view or be volunteering to take *all* the support questions when they come in :)
The one thing I'd ask is that any such PEP *not* advocate for promoting
ther variants as the preferred way of invoking Python on Windows - rather, they should be positioned as a way of making online instructions written for Linux more likely to "just work" for folks on Windows (similar to the utf-8 encoding changes in https://www.python.org/dev/peps/pep-0529/)
Instead, the focus should be on ensuring the "python -m pip install" and "pip install" both work after clicking through the installer without changing any settings, and devising a troubleshooting guide to help folks that are familiar with computers and Python, but perhaps not with Windows, guide folks to a properly working environment.
My preferred solution for this is to rename "py.exe" to "python.exe" (or rather, make a copy of it with the new name), and extend (or more likely, rewrite) the launcher such that:
- if argv == "py.exe", use PEP 514 company/tag resolution to find and
launch Python based on first command line argument
- if argv == "python<numeric tag>.exe", find the matching
PythonCore/<tag> install (where tag may be a partial match - e.g. "python3.exe" finds the latest PythonCore/3.x)
- else, if argv == "<module><numeric tag>.exe, find the matching
PythonCore/<tag> install and launch "-m <module>"
With the launcher behaving like this, we can make as many hard links as we want in its install directory (it only gets installed once, so only needs one PATH entry, and this is C:\Windows for admin installs):
As well as allowing e.g. "py.exe -anaconda36-64 ..." to reliably locate and run non-Python.org installs.
It needs to be fully specced out, obviously, and we may want to move the all-users install to its own directory to reduce clutter, but part of the reason behind PEP 514 was to enable this sort of launcher. It could even extend to "you don't have this version right now, want to download and install it?"
And finally it should be fairly obvious that this doesn't have to be a core Python tool. It has no reliance on anything in core (that isn't already specified in a PEP) and could be written totally independently. I've tried (weakly) to get work time allocated to this in the past, and if it's genuinely not going to get done unless I do it then I'll try again.
Cheers, Steve _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/