4

I aim to have normal version numbers for python wheel releases, like 1.0.0, and branch-specific version numbers for specific branches, like 1.0.0.dev1+hg.5.b11e5e6f0b0b.

Unfortunately, Azure DevOps rejects most version numbers as invalid with one of these two error messages:

HTTPError: 400 Client Error: Bad Request - The package version provided is invalid. Versions should conform to the format described in PEP 440 and be under 128 characters. (DevOps Activity ID: 0000000-AAAA-2222-3333-11111111111) for url: https://pkgs.dev.azure.com/sample/_packaging/sample_libraries/pypi/upload

for version numbers like:

version='1.0.0.1.dev', ok
version='1.0.0.1.dev1', ok
version='1.0.0.1.dev_2', ok
version='1.0.0.1.dev_2_b', FAIL
version='1.0.0.1.dev_2-3', FAIL
version='1.0.0.1.dev_2.3', FAIL
version='1.0.0.1.dev_2.3', FAIL
version='1.0.0.d1.dev', FAIL
version='1.0.0.d.dev', FAIL
version='1.0.0.1d1.dev', FAIL
version='1.0.0.1d1.dev1', FAIL
version='1.0.0.1.dev1-3', FAIL
version='1.0.0.1.dev1.3', FAIL
version='1.0.0.1.dev1.3', FAIL
version='1.0.0.1.1.3', ok
version='1.0.0.1.1-3.3', FAIL

 400 Client Error: Bad Request - The package version provided is invalid. Local version segments are not allowed.

for version numbers like: 1.0.0+33

Only the version numbers marked with "ok" in the segment above were accepted by the Azure pipeline.

Is there any way around this? Is there a way to include a development branch name in the version number of a wheel published in Azure DevOps as an artifact?

hey
  • 2,643
  • 7
  • 29
  • 50

2 Answers2

6

How can I include a branch name in a wheel version number for Azure DevOps artifacts?

I am afraid there is no such a way to include a branch name in a wheel version number for Azure DevOps artifacts.

When we push the python package to the Azure DevOps artifacts, this package need to follow rule PEP 440, which describes a scheme for identifying versions of Python software distributions, and declaring dependencies on particular versions.

Public version identifiers are separated into up to five segments:

  • Epoch segment: N!
  • Release segment: N(.N)*
  • Pre-release segment: {a|b|rc}N
  • Post-release segment: .postN
  • Development release segment: .devN

That the reason why only the version numbers marked with "ok" in the segment above were accepted by the Azure pipeline.

On the other side, PEP440 does allow arbitrary local version labels to be appended to a version specifier, but these must be affixed with a '+', that was the second way you tried. However, Azure Artifacts python package doesn't support this version format at this moment.

There is a user voice about it: Local Version Segments for Python Package Feeds, you can follow with your comments and check the feedback of this issue. I will also follow up this issue, I will send you the latest status of this ticket.

Hope this helps.

zoltanctoth
  • 2,788
  • 5
  • 26
  • 32
Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • Updated link: https://developercommunity.visualstudio.com/t/local-version-segments-for-python-package-feeds/892057 – Ogaday Feb 03 '23 at 16:49
1

Intro

I agree that using .devN where N is an integer is not very convenient. Local Version Identifiers seems interesting here but it was not initially designed for that.

It is probably not available in Azure because of the following recommendations of PEP440:

An "upstream project" is a project that defines its own public versions ... Local version identifiers SHOULD NOT be used when publishing upstream projects to a public index server ... As the Python Package Index is intended solely for indexing and hosting upstream projects, it MUST NOT allow the use of local version identifiers ...

Solution 1

If you consider using a different python package index, which support Local Version Identifiers, just take care with the +. Because if you publish your wheel to this index, this version may be considered usable:

Comparison and ordering of local versions consider each segment of the local version (divided by a .) separately.

And for example, if you publish 1.2.3+${BRANCH_NAME}, 1.2.3+dev${BRANCH_NAME} or 1.2.3+dev.${BRANCH_NAME}, this dev version could involuntarily be installed via a simple pip install your_package or pip install your_package>=1.2.3

So, for dev versions, prefer the following syntax: 1.2.3.dev0+${BRANCH_NAME}

Solution 2

You can use the COMMIT_SHA1 instead of the BRANCH_NAME. Then, you can convert the hexadecimal COMMIT_SHA1 in base 10 to get an integer and to use it with the 0.devN syntax.

Axel Borja
  • 3,718
  • 7
  • 36
  • 50