SoureForge backend: add support for custom tarball name

[akien-mga]

It's not fully clear from the title, but what I want is support for a tarball lookup with the $custom_name-$?version_prefix$version.$ext structure.

Currently the SourceForge backend will assume that the project name is the first part of the tarball name, but it is not always the case.

Example: extremetuxracer https://sourceforge.net/projects/extremetuxracer/files/releases/ Until 0.5beta they did name their tarball extremetuxracer-0.5beta.tar.gz, but then they changed the name to etr, so recent tarballs are etr-0.7.3.tar.xz. Anitya doesn't support that yet so it still shows 0.5beta as latest release.

It might be worked around with a custom regex, but this is something that should be support out of the box in the SourceForge backend IMO.

[pypingou]

Well, anitya allows two fields: one for the name of the tarball one for the name of the project on sourceforge. Adding support for a third name which would be: new name of the tarball seems a little wrong to me, what would we do if they suddenly decide to name their tarball extremetr, a fourth field?

[akien-mga]

I agree that adding support for a third name seems tedious, though does the backend use the anitya project name too in its regex?

If they suddenly decided to rename their tarball, we'd of course not need a fourth field, but would change the custom tarball prefix to the new one. It's not our job to accommodate automatically every possible upstream decision, but we should have the ability to fix our pattern to match upstream divergences when we notice them.

So the history of this example project would be:

Project: ExtremeTuxRacer SourceForge ID: extremetuxracer (won't change)

1. Tarball name: extremetuxracer-0.5beta.tar.gz Custom tarball prefix: n/a (default, SourceForge ID)
2. Tarball name: etr-0.7.3.tar.xz Custom tarball prefix: etr
3. Tarball name: extremetr-0.8.tar.xz Custom tarball prefix: extremetr

For me the SourceForge ID is the indication that tells anitya what SF project to browse (especially when it can't be derived from the project homepage). It does not have to be the pattern used in the tarball, and effectively, in SF projects, it's often not sufficient.

And the problem with SF is that you can't easily use the custom backend for that, as releases are often split in subdirectories in the Files system (and I don't think the folder would work on SF, though I'll admit I haven't tried).

Of course, there are no absolute solutions that would match all use cases. But I believe that adding some more configuration options to the backends would not hurt, if it prevents us from having to find workarounds to backends that don't fit the projects using them. If there's a concern about providing too many options, the "advanced" options could easily be hidden by default and accessible through an advanced form.

Then of course it's a matter of design and how configurable the anitya devs want their backend to be. I'm just starting using it and contributing some feedback and don't expect to be giving directions ;) Still, I could see the use for various more advanced configuration options, especially to control what regex will be used by the backend to some extent (some backends have a version prefix option already, but a version suffix would also be useful in some cases, or custom tarball prefix like here, etc.).

[pypingou]

And the problem with SF is that you can't easily use the custom backend for that, as releases are often split in subdirectories in the Files system (and I don't think the folder would work on SF, though I'll admit I haven't tried).

That's why the SF backend uses the RSS feed ;-)

[pypingou]

For me the SourceForge ID is the indication that tells anitya what SF project to browse (especially when it can't be derived from the project homepage). It does not have to be the pattern used in the tarball, and effectively, in SF projects, it's often not sufficient.

Indeed, and basically the approach we took so far is: anitya project name == name of the tarball, sourceforge name == what you call sourceforge ID

So in this case, the project should be renamed ptr which I agree kinda suck as name :/

[akien-mga]

Indeed, and basically the approach we took so far is: anitya project name == name of the tarball, sourceforge name == what you call sourceforge ID

That's interesting to note for the #364 discussion, as it therefore quite defines what kind of "upstream name" we should be aiming for (tarball name).