Pip: Pip fails to install on systems with a date way ahead in the future

Created on 2 Oct 2017 · 6Comments · Source: pypa/pip

Pip version: 9.0.1
Python version: 2.7.12
Operating system: Windows 10

Description:

Pip is failing to install when the system date set is way ahead in the future. This has been tested in a system with a BIOS date set to 01/01/2900.
Installing the wheel fails and shows an exception error: ushor format requires 0 <= number <= USHRT_MAX.
This is nothing new. The same error was reported in the library zipfile.py that can't write files time stamped with a date before 1980. Take a look here.

What I've run:

When running python installer downloaded from python.org, pip is never installed (no Scripts folder) and no issue is raised... It's just not there.
When trying to install pip doing:

python pip-9.0.1-py2.py3-none-any.whl/pip install --no-index pip-9.0.1-py2.py3-none-any.whl

I get the following exception:

Traceback (most recent call last):
  File "c:\python27\lib\site-packages\pip\basecommand.py", line 209, in main
    status = self.run(options, args)
  File "c:\python27\lib\site-packages\pip\commands\install.py", line 317, in run
    prefix=options.prefix_path,
  File "c:\python27\lib\site-packages\pip\req\req_set.py", line 732, in install
    **kwargs
  File "c:\python27\lib\site-packages\pip\req\req_install.py", line 835, in install
    self.move_wheel_files(self.source_dir, root=root, prefix=prefix)
  File "c:\python27\lib\site-packages\pip\req\req_install.py", line 1030, in move_wheel_files
    isolated=self.isolated,
  File "c:\python27\lib\site-packages\pip\wheel.py", line 491, in move_wheel_files
    maker.make_multiple(['%s = %s' % kv for kv in console.items()])
  File "c:\python27\lib\site-packages\pip\_vendor\distlib\scripts.py", line 383, in make_multiple
    filenames.extend(self.make(specification, options))
  File "c:\python27\lib\site-packages\pip\_vendor\distlib\scripts.py", line 372, in make
    self._make_script(entry, filenames, options=options)
  File "c:\python27\lib\site-packages\pip\_vendor\distlib\scripts.py", line 276, in _make_script
    self._write_script(scriptnames, shebang, script, filenames, ext)
  File "c:\python27\lib\site-packages\pip\_vendor\distlib\scripts.py", line 217, in _write_script
    zf.writestr('__main__.py', script_bytes)
  File "c:\python27\lib\zipfile.py", line 1248, in writestr
    self.fp.write(zinfo.FileHeader(zip64))
  File "c:\python27\lib\zipfile.py", line 365, in FileHeader
    len(filename), len(extra))
error: ushort format requires 0 <= number <= USHRT_MAX

auto-locked awaiting response

Source

fr-ez

Most helpful comment

Agreed. Unless there's a clear and compelling use case for this, I'm inclined to consider it as a broken system, and we're not going to fix it. Apart from anything else, the actual error seems to be from the zipfile module, so it's a limitation of that (or more likely, of the zip format itself). So it wouldn't be a pip issue anyway.

pfmoore on 2 Oct 2017

👍2

All 6 comments

Question is: why should one expect this to work? Should we not be able to assume that the date on the system is vaguely sane? My take on this would be that if pip still is in wide use in 2850, we can start worrying about it then.

obestwalter on 2 Oct 2017

pfmoore on 2 Oct 2017

👍2

Absolutely, makes sense. This happened when testing systems that had that date, because of other tests that needed to be done, so yes, I guess it's ok to consider it a broken system.
I just wanted to report it so that you could be aware of this issue.

fr-ez on 2 Oct 2017

❤1

Thanks - we appreciate you taking the time to let us know (apart from anything else, it's interesting to find out some of the situations pip gets used in! :smile:)

pfmoore on 2 Oct 2017

Is there anything actionable here then?