Python setup tools normalizes version name based on common naming convention

Question

Error

/root/.local/lib/python3.7/site-packages/setuptools/dist.py:476: UserWarning: Normalizing '2.1.0c1' to '2.1.0rc1'
  normalized_version,
[Pipeline] sh
+ python3 -m twine upload --config-file .pypirc -r nesus dist/forecasting_model-2.1.0c1.tar.gz
InvalidDistribution: Cannot find file (or expand pattern): 'dist/forecasting_model-2.1.0c1.tar.gz'

My code for naming convention

 model_version_trunc = re.split("a|b|c", current_version)[0] if len(re.split("a|b|c", current_version)) > 0 else current_version
    sub_version = int(re.split("a|b|c", current_version)[1]) if len(re.split("a|b|c", current_version)) > 1 else 1
    VERSION = current_version

    if BRANCH == 'workbench':
        letter = 'a'
    elif BRANCH == 'development':
        letter = 'b'
    elif BRANCH == 'master':
        sub_version = ''
        letter = ''
    else:
        letter = 'c'

    VERSION = f'{model_version_trunc}{letter}{sub_version}'

    # Check Version
    session = HTMLSession()
    r = session.get(MODEL_LIBRARY)
    versions_so_far = r.html.links
    version_already_exists = list(set([f'{VERSION}/']).intersection(versions_so_far))
    logger.info(f'Updated Version: {VERSION}')
    logger.info(f'Version Exists: {version_already_exists}')

    if len(version_already_exists) > 0:
        for x in version_already_exists:
            ''' 
                Fallback if versions are similar:

                If a version is an alpha/beta/branch release, update the release number
                If a version is just the standard version then udpate the minor version.
            '''

I checked the link here -

https://packaging.python.org/guides/distributing-packages-using-setuptools/#choosing-a-versioning-scheme

for the popular naming convention.

Is there a way to fix this sort of sentience!

Answer 1

Your version scheme is not compatible with PEP 440. The link you mentioned in the question explicitly states:

Different Python projects may use different versioning schemes based on the needs of that particular project, but all of them are required to comply with the flexible public version scheme specified in PEP 440 in order to be supported in tools and libraries like pip and setuptools.

PEP 440 allows only five suffixes: a, b, rc, post and dev.

Also note that a and b suffixes identify alpha and beta releases, so check whether your versioning scheme reflects that (does the workbench branch really contain the alpha release?).

If you need to store additional information in the version, you can use the local version identifier to separate the version part. Examples:

1.2.3+spam
1.0.0.dev999+eggs123.bacon456

However, restating PEP 440 once again:

Local version identifiers SHOULD NOT be used when publishing upstream projects to a public index server, but MAY be used to identify private builds created directly from the project source. [...] As the Python Package Index is intended solely for indexing and hosting upstream projects, it MUST NOT allow the use of local version identifiers.