Override `<number>` when creating a pre-release

[BatmanAoD]

I would like to make PyO3 packages (Python packages generated from Rust code) and be able to have different prerelease suffixes from multiple branches or pull-requests at once. I thought an easy way to do this would be to include a pull-request number or other such numeric identifier in the pre-release label, but this actually causes an error when trying to generate a Python package, because -foo<num>.<num> isn't a valid Python version string according to PEP 440. So I think the only way to generate a Knope prerelease version that includes a numeric identifier like this (without resorting to --override-version and constructing the version myself) would be to have a way to just specify what number I want the pre-release label to have.

[dbanty]

This is basically --prerelease-number instead of --prerelease-label?

[BatmanAoD]

I'm trying to remember the context here, because I don't quite understand from my description why overriding the number would make the version string conform with the PEP. I'll try to reacquaint myself with the issue this week.

[BatmanAoD]

Okay, here are the current normative Python rules: https://packaging.python.org/en/latest/specifications/version-specifiers/#pre-release-separators

The problem is that the rules specify a finite number of valid prerelease labels: alpha, beta, c, pre, preview, a, b, and rc. (The labels also have normative semantics: "alpha", "beta", or "release candidate".) So it is not possible to have arbitrary prerelease labels to ensure that prereleases generated from different branches don't conflict.

My idea for resolving this was to guarantee that the numeric components can't clash, presumably by using large, artificially-constructed numbers like 03704 for "prerelease 4 on PR 37". Even that is pretty clearly going against the spirit of the Python rules, but it would at least ensure that Python tools won't choke on the numbers. (I don't recall what specific tool choked for me; probably either Poetry or Maturin.)

So, yes, to support that as a workaround for anyone who wants to have "valid but unseemly" Python prerelease numbers, Knope would need something like a --prerelease-number flag. That said, I'm not sure what the semantics would be: would it require --prerelease-label as well, or would it imply a default label such as rc?