If "uname -rs" returns no output, _parse_uname_content causes exception

[pcolmer]

Python version 3.5.2
OS: Ubuntu 16.04.6 LTS

I'm trying to install pip by using python3 get-pip.py --user. This is failing with "IndexError: list index out of range". Running a debugger shows that the root cause seems to be that uname -rs returns no output on my system. The individual options work but not when combined.

Here is the exception stack trace:

Exception:
Traceback (most recent call last):
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_internal/cli/base_command.py", line 143, in main
    status = self.run(options, args)
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_internal/commands/install.py", line 259, in run
    with self._build_session(options) as session:
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_internal/cli/base_command.py", line 79, in _build_session
    insecure_hosts=options.trusted_hosts,
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_internal/download.py", line 337, in __init__
    self.headers["User-Agent"] = user_agent()
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_internal/download.py", line 100, in user_agent
    zip(["name", "version", "id"], distro.linux_distribution()),
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_vendor/distro.py", line 120, in linux_distribution
    return _distro.linux_distribution(full_distribution_name)
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_vendor/distro.py", line 675, in linux_distribution
    self.version(),
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_vendor/distro.py", line 741, in version
    self.uname_attr('release')
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_vendor/distro.py", line 910, in uname_attr
    return self._uname_info.get(attribute, '')
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_vendor/distro.py", line 550, in __get__
    ret = obj.__dict__[self._fname] = self._f(obj)
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_vendor/distro.py", line 1037, in _uname_info
    return self._parse_uname_content(content)
  File "/tmp/tmpyrz_zul1/pip.zip/pip/_vendor/distro.py", line 1042, in _parse_uname_content
    match = re.search(r'^([^\s]+)\s+([\d\.]+)', lines[0].strip())
IndexError: list index out of range

[pcolmer]

What's really strange about this is that the documentation says:

The distro package implements a robust and inclusive way of retrieving the information about a distribution based on new standards and old methods, namely from these data sources (from high to low precedence):

The os-release file /etc/os-release, if present.
The output of the lsb_release command, if available.
The distro release file (/etc/*(-|_)(release|version)), if present.
The uname command for BSD based distrubtions.

but my system does have the first three:

$ more /etc/os-release
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.6 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 16.04.6 LTS
Release:        16.04
Codename:       xenial

$ ls /etc/*release
/etc/lsb-release  /etc/os-release
$ ls /etc/*version
/etc/debian_version  /etc/ec2_version

So quite why the code is relying on the lowest preference option is baffling me.

[pcolmer]

I've found what was "breaking" uname -rs - there was a local script installed in the user's path. Not sure where it came from :(. Removing that allowed the correct uname to be used.

[brejoc]

We could do something like this in _uname_info:

        content = self._to_str(stdout).splitlines()
        if content and len(content) >= 1:
            return self._parse_uname_content(content)

        return {}

But then we would drop it just silently. Not sure if that is what we want.

[HorlogeSkynet]

@brejoc I guess content and len(content) >= 1 would be a nit pick ; checking for content boolean evaluation should be sufficient.

[HorlogeSkynet]

Addressed in #304, we can even include it in 1.6.0 if everyone's OK with that. Cheers

[HorlogeSkynet]

Closing here as #304 is almost there.