This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: packaging.pypi.dist should abstract download errors.
Type: behavior Stage: resolved
Components: Distutils2 Versions: Python 3.3
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: tarek Nosy List: alexis, eric.araujo, michael.mulich, tarek
Priority: normal Keywords:

Created on 2011-06-19 20:20 by michael.mulich, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (2)
msg138658 - (view) Author: Michael Mulich (michael.mulich) * Date: 2011-06-19 20:20
packaging.pypi.dist should abstract download errors, especially those from external sources. Download errors are currently reported from urllib. We should probably be using packaging.errors.PackagingPyPIError in this situation. Other suggestions?

Example case:

sake version 0.0.0 has a external download URL that throws a 404 (see also When attempting to download this release, we receive a ValueError from urllib, which is not very detailed and could mean a number of things.

Traceback (most recent call last):
  ... [dev project] ...
  File ".../cpython/Lib/packaging/pypi/", line 167, in download
  File ".../cpython/Lib/packaging/pypi/", line 302, in download
    path + "/" + archive_name)
  File ".../cpython/Lib/urllib/", line 150, in urlretrieve
    return _urlopener.retrieve(url, filename, reporthook, data)
  File ".../cpython/Lib/urllib/", line 1600, in retrieve
    block =
ValueError: read of closed file
msg138660 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-06-19 20:24
I agree that we can wrap exceptions to provide more useful info where needed.  It’s not necessary, however, to always catch exceptions and raise Packaging*Errors instead: distutils and packaging are documented to raise ValueError and other standard exceptions in some cases.
Date User Action Args
2022-04-11 14:57:18adminsetgithub: 56575
2014-03-13 03:56:54eric.araujosetstatus: open -> closed
resolution: out of date
stage: resolved
2011-06-19 20:24:23eric.araujosetmessages: + msg138660
2011-06-19 20:20:46michael.mulichcreate