Would something like this be helpful? (`python -m pip` seems to work fine after `conda install pip` after a miniconda install)
https://gist.github.com/westurner/80e81cd4bf9b79acb5989622f2621655 ```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 <steve.do...@python.org> wrote: > On 15Nov2017 0617, Nick Coghlan wrote: > >> On 15 November 2017 at 22:46, Michel Desmoulin <desmoulinmic...@gmail.com >> <mailto:desmoulinmic...@gmail.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[0] == "py.exe", use PEP 514 company/tag resolution to find and > launch Python based on first command line argument > * if argv[0] == "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[0] == "<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): > * python.exe > * python2.exe > * python3.exe > * python3.6.exe > * pip.exe > * pip2.exe > * pip3.exe > > 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 > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
