#61135 closed enhancement (fixed)
pypy: distfile is archive.tar.gz
| Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | danchr (Dan Villiom Podlaski Christiansen) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | ||
| Port: | pypy |
Description
The pypy port's distfile name is archive.tar.gz. This is a bad name for a distfile because it tells us nothing about the name of the software or the version. A better distname would be the MacPorts default, ${name}-${version}${extract.suffix}. If the upstream project's server doesn't offer the file with a reasonable name, it can be overridden by appending any query string parameter to the master_sites; see PortfileRecipes#fetchwithgetparams.
Change History (7)
comment:1 follow-up: 2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
comment:2 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)
Replying to ryandesign:
It looks like reasonably named distfiles are available at https://downloads.python.org/pypy/. Could those be used instead?
Yeah, it's just that the naming is somewhat inconsistent due to including the Python 3.x version. I used a subdirectory instead, as you can see on https://distfiles.macports.org/pypy/ — was that not sufficient?
If not, I'll fix it at the next upgrade, or when addressing #61136 — I'd rather not have to build PyPy more than strictly necessary.
comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Specifying a different dist_subdir is sufficient for avoiding the checksum mismatches that would otherwise result from using unversioned distfiles, but it would still be better to use a distfile name that contains the name and version of the software, if such a distfile is available from upstream. It's fine to wait to fix this to coincide with another planned update.
comment:4 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
comment:5 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)
It turned out that GitLab/Heptapod just responded with whatever name we request, so the fix was quite trivial 🙂
comment:6 follow-up: 7 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Great! Yeah, github works that way too, and the github 1.0 portgroup takes advantage of that.
I see that you're now using the gitlab 1.0 portgroup. I haven't looked into that one but I would hope that its default behavior would give you sensible distfile names without you needing to override anything.
comment:7 Changed 4 years ago by danchr (Dan Villiom Podlaski Christiansen)
Replying to ryandesign:
Great! Yeah, github works that way too, and the github 1.0 portgroup takes advantage of that.
I see that you're now using the gitlab 1.0 portgroup. I haven't looked into that one but I would hope that its default behavior would give you sensible distfile names without you needing to override anything.
Normally, yeah, it would: I've used that in other ports. But that might not work terribly well with different subports, within the same port, fetching from different tags in different branches… PyPy really is weird 🙂
It looks like reasonably named distfiles are available at https://downloads.python.org/pypy/. Could those be used instead?