On 15/05/2015 19:55, Chris Angelico wrote:
On Sat, May 16, 2015 at 4:45 AM, Ethan Furman <et...@stoneleaf.us> wrote:
On 05/15/2015 06:04 AM, Mark Lawrence wrote:
C:\Users\Mark\Documents\MyPython>pip install --no-cache-dir
--trusted-host http://www.lfd.uci.edu/ -U -f
http://www.lfd.uci.edu/~gohlke/pythonlibs/ numba
Collecting numba
This repository located at www.lfd.uci.edu is not a trusted host, if
this repository is available via HTTPS it is recommend to use HTTPS
instead, otherwise you may silence this warning with '--trusted-host
www.lfd.uci.edu'.
DEPRECATION: Implicitly allowing locations which are not hosted at a
secure origin is deprecated and will require the use of --trusted-host
in the future.
Downloading numba-0.18.2.tar.gz (507kB)
100% |################################| 507kB 373kB/s
I particularly like how, when you specify --trusted-host, you still get all
the warnings to use --trusted-host... not.
Actually, I suspect the note is telling you to use "--trusted-host
www.lfd.uci.edu" rather than "--trusted-host http://www.lfd.uci.edu/";
- so it's as if the option wasn't specified at all. But pip can be a
little hard to understand sometimes (just ask Prince Edward, who had
no end of trouble understanding the poor chipmonk!), so I may very
well be wrong here.
ChrisA
I'm putting this here FTR as I'm too knackered to follow up right now.
After a bit more digging I ended up with this.
C:\Users\Mark\Documents\MyPython>pip install --trusted-host
www.lfd.uci.edu/ -U
http://www.lfd.uci.edu/~gohlke/pythonlibs/numba-0.18.2-cp34-none-win_amd64.whl
Collecting numba==0.18.2 from
http://www.lfd.uci.edu/~gohlke/pythonlibs/numba-0.18.2-cp34-none-win_amd64.whl
Downloading
http://www.lfd.uci.edu/~gohlke/pythonlibs/numba-0.18.2-cp34-none-win_amd64.whl
Exception:
Traceback (most recent call last):
File "C:\Python34\lib\site-packages\pip\basecommand.py", line 246,
in main
status = self.run(options, args)
File "C:\Python34\lib\site-packages\pip\commands\install.py", line
342, in run
requirement_set.prepare_files(finder)
File "C:\Python34\lib\site-packages\pip\req\req_set.py", line 345,
in prepare_files
functools.partial(self._prepare_file, finder))
File "C:\Python34\lib\site-packages\pip\req\req_set.py", line 290,
in _walk_req_to_install
more_reqs = handler(req_to_install)
File "C:\Python34\lib\site-packages\pip\req\req_set.py", line 487,
in _prepare_file
download_dir, do_download, session=self.session,
File "C:\Python34\lib\site-packages\pip\download.py", line 827, in
unpack_url
session,
File "C:\Python34\lib\site-packages\pip\download.py", line 677, in
unpack_http_url
unpack_file(from_path, location, content_type, link)
File "C:\Python34\lib\site-packages\pip\utils\__init__.py", line
630, in unpack_file
flatten=not filename.endswith('.whl')
File "C:\Python34\lib\site-packages\pip\utils\__init__.py", line
509, in unzip_file
zip = zipfile.ZipFile(zipfp, allowZip64=True)
File "C:\Python34\lib\zipfile.py", line 937, in __init__
self._RealGetContents()
File "C:\Python34\lib\zipfile.py", line 978, in _RealGetContents
raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file
The same file installed perfectly when downloaded and installed in two
steps. Whether this is simply a known bug with zipfile handling, pip
itself, a combination of both or what I've no idea.
I find it slightly irritating that a tool recommended by the Python
Packaging Authority behaves in such a way, but then I didn't have to dip
into my pocket to pay for it and certainly won't lose any sleep over it
as there's such a simple work around.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
