Search code examples
pythonmicroservicespypisemantic-versioningpython-poetry

Development versions management in private pypi repository

We are working on a product based on micro services and we are encountering some difficulties in the management of development versions of self-developed python packages shared between the components.

We would like to be able develop different features of the microservice alongside its dependencies, pulling separate development versions from our private pypi repository without interfering with stable releases.

Example

  • utility package XYZ is shared across multiple services, currently at version 1.2.5
  • microservice A depends on XYZ version ^1.0.0
  • microservice B depends on XYZ version ^1.0.0
  • developer 1 is working on microservice A for feature foo
  • developer 2 is working on microservice B for feature bar

Scenario

Both developers need to change XYZ to add core functionality that could be reused by other services in the future. Both developers branch from the current stable 1.2.5 version and start working on their features. At the end of the sprint, both of their branches will be merged and version 1.3.0 will be published.

In the meantime, during development, the developers want to be able to test the integration between the microservice they are working on and the package.

Problem

We use poetry to manage our dependencies, and we would like to use the private pypi repository to specify intervals of versions instead of hardcoding a tag or branch name when pulling from the private git repository directly.

We initially thought we could name our versions like in the example below, and make the microservice under development depend on this specific version

1.3.0-foo
1.3.0-bar

But we discovered that the PEP standard for version naming does not allow us to add custom labels to version.

Is there a best practice or workaround to keep working with our private pypi repository?

Solution

  • As I can see from the doc you should be able to specify a dev suffix like explained here https://www.python.org/dev/peps/pep-0440/#examples-of-compliant-version-schemes

    I'm looking at the section:

    "major.minor" versioning with developmental releases, release candidates and post-releases for minor corrections:

0.9
1.0.dev1
1.0.dev2
1.0.dev3
1.0.dev4

    What if dev 1 name his version as 1.3.dev1 and dev 2 as 1.3.dev2 and so on?