Soften up-to-date check

[jakirkham]

Currently if conda-smithy is not on the latest version during a rerender, it will raise an error

However if the latest conda-smithy is marked broken, this behavior persists without taking into account the latest non-broken version is older than the latest version naively checked

This can leave bot codes that rerender in a dysfunctional state. Meaning core needs to hunt down and fix these lines at the same time a broken conda-smithy emerges (the exact same time we may not have bandwidth to fix it for the same reason)

Some options we might consider here:

• Teach the up-to-date check about broken versions
• Soften the up-to-date check to a warning unless a flag is passed to create the error
• ...?

Please feel free to suggest more

[jaimergp]

Teach the up-to-date check about broken versions

Definitely this. It's a pity that we don't publish the broken label anymore, so I guess we'll have to use the repodata.json sources directly.

[jaimergp]

We can also mark the release as "not latest" in GH? If that's what we are checking.

[jakirkham]

Thinks it is using this logic

conda-smithy/conda_smithy/configure_feedstock.py

Lines 2191 to 2204 in 123be4e

	def get_most_recent_version(name):
	from conda_build.conda_interface import VersionOrder
	request = requests.get(
	"https://api.anaconda.org/package/conda-forge/" + name
	)
	request.raise_for_status()
	pkg = max(
	request.json()["files"], key=lambda x: VersionOrder(x["version"])
	)
	PackageRecord = namedtuple("PackageRecord", ["name", "version", "url"])
	return PackageRecord(name, pkg["version"], "https:" + pkg["download_url"])

We do mark them broken, but they are still under main as well

Do we need to check a different URL than we are using to pick up the repodata patching?

[jaimergp]

I think we can use this variation:

pkg = max(
  [
    f 
    for f in request.json()['files'] 
    if "broken" not in f["labels"]
  ],
  key=lambda x: VersionOrder(x['version']),
)