[Python-ideas] Looking for input to help with the pip situation

[Wes Turner]

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.dower at python.org> wrote:

> On 15Nov2017 0617, Nick Coghlan wrote:
>
>> On 15 November 2017 at 22:46, Michel Desmoulin <desmoulinmichel at gmail.com
>> <mailto:desmoulinmichel at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171116/6a55bf9b/attachment-0001.html>