Optional spkg symengine_py has an invalid upstream url

[culler]

Environment

- **All OS's**:
- **10.3.rc2**:

Steps To Reproduce

Build Sage with the symengine_py optional package enabled

Config log

config.log

Package logs

symengine_py-0.11.0.log

Additional Information

The problem here is that the file downloaded from the upstream url given in the spkg, namely:
https://pypi.io/packages/source/p/symengine/symengine-0.11.0.tar.gz
is not the same as the file downloaded from the url specified on pypi, namely:
https://files.pythonhosted.org/packages/fe/53/6289257bca1b326740460ea31cbc266ae171541b65bbada4b8d31f8ed3e1/symengine-0.11.0.tar.gz

The first file has md5 hash 5a859121a56e81179bef72816fb82ccd while the second has the md5 hash specified both in the checksums.ini file and on PyPI, namely d10f4ba5c27b09ef234fcafddf824ce5.

This is probably the tip of an iceberg. It seems that all of wheel spkgs use upstream urls at pypi.io instead of the pypi urls which include a uuid. Apparently one can no longer trust the pypi.io links.

Checklist

• I have searched the existing issues for a bug report that matches the one I want to file, without success.
• I have read the documentation and troubleshoot guide

[culler]

Note that the "p" in the pypi.io url should be "s". But this seems to make no difference. You get the same file with "p" as with "s".

[mkoeppe]

I'm getting 404 on https://pypi.io/packages/source/p/symengine/symengine-0.11.0.tar.gz after redirects

wget https://pypi.io/packages/source/p/symengine/symengine-0.11.0.tar.gz                                  git:symengine_py_upstream
--2024-03-06 10:07:21--  https://pypi.io/packages/source/p/symengine/symengine-0.11.0.tar.gz
Resolving pypi.io (pypi.io)... 2a04:4e42::223, 2a04:4e42:600::223, 2a04:4e42:400::223, ...
Connecting to pypi.io (pypi.io)|2a04:4e42::223|:443... connected.
HTTP request sent, awaiting response... 301 Redirect to Primary Domain
Location: https://pypi.org/packages/source/p/symengine/symengine-0.11.0.tar.gz [following]
--2024-03-06 10:07:21--  https://pypi.org/packages/source/p/symengine/symengine-0.11.0.tar.gz
Resolving pypi.org (pypi.org)... 2a04:4e42:400::223, 2a04:4e42:600::223, 2a04:4e42:200::223, ...
Connecting to pypi.org (pypi.org)|2a04:4e42:400::223|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://files.pythonhosted.org/packages/source/p/symengine/symengine-0.11.0.tar.gz [following]
--2024-03-06 10:07:22--  https://files.pythonhosted.org/packages/source/p/symengine/symengine-0.11.0.tar.gz
Resolving files.pythonhosted.org (files.pythonhosted.org)... 2a04:4e42:a::223, 151.101.196.223
Connecting to files.pythonhosted.org (files.pythonhosted.org)|2a04:4e42:a::223|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2024-03-06 10:07:22 ERROR 404: Not Found.

[culler]

This has changed since this morning. I am now getting a 301 with curl.

In any case, the official pypi url with the big hash value embedded in it works fine. I see no reason why the upstream url specified in the spkg should not be the official pypi url.

The bigger question is how many other spkgs have upstream urls which are now broken. The PyPI documentation says not to rely on those pypi.io urls. Maybe they have now broken them.

[mkoeppe]

I see no reason why the upstream url specified in the spkg should not be the official pypi url.

Sure, we'll just need to change the sage -package update[-latest] script a little bit.

[culler]

Actually, I don't think it changed since this morning. I think the bad file I was getting was just an html file reporting the 301 error, not a different tarball. Not that it makes much difference as far as Sage is concerned if Sage ever tries to use the upstream url.

[mkoeppe]

Actually the upstream url just has a typo. I'm fixing it in #37762