On Nov 2, 2017, at 06:36, Russell Jones wrote: > On 02/11/17 11:06, Ryan Schmidt wrote: > >> On Nov 2, 2017, at 05:49, Russell Jones wrote: >> >>> I'm working on a few python ports using the Python 1.0 PortGroup, and I get >>> 404s for the download link. e.g. for Python module xyz version 1.2.3, it >>> looks for https://pypi.python.org/packages/source/x/xyz/xyz-1.2.3.tar.gz >>> Trying this for a few random modules, it always comes back 404. >>> >>> Looking at the output of "pip -vvv install ..." pip obtains an intermediate >>> page, https://pypi.python.org/simple/xyz/ , which is a very basic >>> (unterminated) html page with a list of a tags, with href element set to >>> the relative URL of the downloads for all versions, each of which contains >>> a long string of hex and appears random. It looks like pip parses this and >>> picks the link for the chosen version (or sorting, maybe with >>> distutils.version.LooseVersion, and choosing the highest: the list of links >>> is not sorted). I guess the PortGroup needs to emulate this behaviour. >>> >>> Any thoughts on how/whether this should be implemented in MacPorts? >> The python-1.0 portgroup doesn't seem to be involved in the download process >> at this time. It's all handled by the pypi fetchgroup, right? (In >> _resources/port1.0/fetch/mirror_sites.tcl) >> >> The pypi fetchgroup also looks for files on files.pythonhosted.org, and that >> works, right? If so, why does it need to also look on pypi.python.org? > > Right. I had a feeling I was missing something. > > Ah, hold on. The extension's changed to .zip from .tar.gz, that's the > problem. Sorry for the noise.
Well, but still, should we remove pypi.python.org from the pypi fetchgroup, or are there some ports for which it still works where files.pythonhosted.org wouldn't work?
