toolbox doesn't understand "rawhide" version name

[hadess]

$ rpm -q toolbox
toolbox-0.0.97-1.fc33.x86_64
$ toolbox create -r rawhide
Error: invalid argument for '--release'
Run 'toolbox --help' for usage.

[fedelibre]

For the records, even if Fedora 34 has not been branched yet, toolbox can find a f34 image:

$ toolbox create --distro fedora --release f34
Image required to create toolbox container.
Download registry.fedoraproject.org/f34/fedora-toolbox:34 (500MB)? [y/N]: y
Created container: fedora-toolbox-34
Enter with: toolbox enter --release 34

[debarshiray]

The problem is that we don't have an easy way to map rawhide to a numerical value in a way that would stay updated over time without manual intervention.

One option that was suggested in #fedora-devel on Freenode was to parse the metadata in the Fedora RPM repositories for rawhide. That's something that needs to be explored because I don't know off-hand how easy or difficult that would be.

[debarshiray]

It seems to me that the best candidate is to use Fedora's package DB collections API that's also used by GNOME Software.

(Thanks to @AdamWill and @kalev for suggesting that.)

Another option that was presented to me in #fedora-devel on Freenode was to parse the branch names of the fedora-release Git repository.

[AdamWill]

So to give my standard explanation of this stuff for the record:

• The "collections API" isn't really an API any more and hasn't been for years. It's a static JSON file that releng update by hand. If they forget to update it or make a booboo while doing it, the data will be wrong. Both these things have happened more than once.
• I have some code that needs this same thing, and the way I do it is: rawrel = str(fedfind.helpers.get_current_release(branched=True) + 1). That uses my fedfind library, which formerly used the collections JSON as its data source, then tried using Bodhi's releases API for a bit, and right now is using my own hand-maintained JSON (on the theory that at least I can fix that one without needing someone else to run a playbook), though I might ping it back to the collections JSON.
• I'm currently trying to get some momentum behind a project I wrote called releasestream that is intended to work as a better/more reliable/more automated source of this kind of information. The idea would be to deploy an official Fedora releasestream instance and have system/scripts that do release-y things, like branching and EOL and so on, also update releasestream at the same time.

[debarshiray]

Thanks for putting that on record. For what it's worth, I heartily endorse your efforts on releasestream.

[juhp]

Personally I just use https://pdc.fedoraproject.org/rest_api/v1/product-versions/ for this.
Bodhi's API might be slightly more precise, depending on the exact use-case.

[AdamWill]

The limitation of PDC is it doesn't have full lifecycle info (it just has 'active' or not; it doesn't distinguish pre-release from stable). I also don't know these days how exactly it gets updated and whether that's any more reliable than the collections JSON. The issue I had with Bodhi is that releases are changed from pre-release to stable state in Bodhi some days before they're actually publicly available.

For toolbox's purposes, neither of those should really be a problem, so you could potentially use either of those sources too. Rawhide's version number should always be one higher than whatever the highest numbered release provided by the data source is.