I have a library (let's call it my_lib) and an application (my_app) structured in two Python packages where my tool my_app requires my_lib in the requirements.txt. In practice, I often develop a feature in my_app where the underlying added functionality is added to my_lib and then utilized in my_app (to re-use library my_lib in another setting).
I develop using Gitflow development principle and have a CI stage for both packages in a feature branch for both packages (let's call them feature/my_feature_in_lib and feature/my_feature_in_app for the argument's sake here). In CI, e.g., unit testing and package upload to a (private) PyPI is done.
Of course, I don't want to merge feature/my_feature_in_lib into the integration branch of my_lib before I properly tested it, which is often done in conjunction with feature/my_feature_in_app in CI.
Ideally, I would want feature/my_feature_in_lib to create an artifact / package that is then consumed by my_app in it's requirements.txt. I currently use setuptools_scm for a SemVer-like auto-incrementation of the version number (such as 0.10.1.post1). However, this scheme can lead to version duplications if working with multiple feature branches in parallel (which is why I currently only create artifacts on the integration branch).
Tools such as GitVersion in the C# world allow for version identifiers that contain feature branch specific identifiers, such as 1.2.3-alpha.feature-a682956d. However, PEP-440 forbids the use of such versioning schemes and twine even rejects such uploads.
What is the optimal way to solve these dependency issues over package-boundaries while maintaining a SemVer-like automatic version incrementation?
Thanks in advance!