I develop a Python library using Gitflow development principle and have a CI stage for unit testing and package upload to a (private) PyPI. I want to consume the uploaded package for testing purposes before I merge it back to the integration branch.

Other package managers (and popular tools) allow for version identifiers that contain feature branch specific identifiers, such as 1.2.3-my-feature-alpha.1 in compliance with SemVer. However, PEP-440 forbids the use of such versioning schemes and twine even rejects such uploads.

What is the correct (or a workable) approach to name Python package versions if wanting to create such pre-releases (that potentially can happen in parallel with multiple feature branches) without version identifier conflicts in compliance with PEP-440?

i am too thinking about this.

Although not intended for this use, you could misuse the local version identifier noted in the PEP-440, see: https://www.python.org/dev/peps/pep-0440/#toc-entry-5

in your case it would be 1.2.3+my-feature.alpha.1

releases with local version identifiers are ignored when querying releases with a compatible public version identifier like 1.2.3, but could still be queried when directly selecting a release with a local version identifier 1.2.3+my-feature-alpha.1

my comment is not a recommendation, it just mirrors the thoughts i had over the same problem.