Fix TestPyPI publish failure with dynamic dev versioning

[Copilot]

TestPyPI publish job fails with "File already exists" error when the workflow runs on pushes because PyPI registries don't allow overwriting existing versions.

Changes

1. Dynamic Versioning with setuptools_scm

Implemented automatic version generation using setuptools_scm to distinguish between tagged releases and development builds:

• Tagged releases (e.g., git tag 0.4.6): Use the tag version as-is → 0.4.6
• Non-tagged commits: Auto-generate dev versions → 0.4.7.dev1, 0.4.7.dev2, etc.

pyproject.toml changes:

[build-system]
requires = ["setuptools>=61.0", "setuptools-scm>=8"]

[project]
dynamic = ["version"]

[tool.setuptools_scm]
version_scheme = "guess-next-dev"
local_scheme = "no-local-version"

2. Workflow Updates

• Added fetch-depth: 0 to checkout action to fetch full git history (required for setuptools_scm)
• Added skip-existing: true to TestPyPI publish step as a fallback safety measure

- uses: actions/checkout@v4
  with:
    fetch-depth: 0  # Fetch all history for setuptools_scm
    
- name: Publish distribution 📦 to TestPyPI
  uses: pypa/gh-action-pypi-publish@release/v1
  with:
    repository-url: https://test.pypi.org/legacy/
    skip-existing: true
    verbose: true

Benefits

• PEP 440 compliant: All generated versions follow Python packaging standards
• No version conflicts: Each commit gets a unique version number
• Clear distinction: Dev versions (.dev suffix) are easily distinguishable from releases
• Automated: No manual version bumping required between releases

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Pip package push fails</issue_title>
<issue_description>Problem: Building roboreg as a pip package works, however it can not be pushed neither to testpypi (nor probably to pypi). Investigate the error.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Pip package push fails #122

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Haydnspass]

@copilot is it possible to somehow indicate that those are dev versions? adding a .dev to the version? or is that non-compliant?

[Copilot]

@copilot is it possible to somehow indicate that those are dev versions? adding a .dev to the version? or is that non-compliant?

Yes! I've implemented dynamic versioning with setuptools_scm. Now non-tagged pushes will automatically get .dev suffixes (e.g., 0.4.7.dev1, 0.4.7.dev2), while tagged releases keep clean versions (e.g., 0.4.6). This is PEP 440 compliant and solves the TestPyPI upload issue.

Changes in commit f8f9bc8:

• Added setuptools_scm to build dependencies
• Configured version_scheme = "guess-next-dev" and local_scheme = "no-local-version"
• Updated workflow to fetch full git history for version detection

[Haydnspass]

@copilot where does it get it from?

[Copilot]

The version comes from git tags and commit history via setuptools_scm (configured in lines 59-61). When building:

• On a tagged commit (e.g., git tag 0.4.6): version = 0.4.6
• 2 commits after tag 0.4.6: version = 0.4.7.dev2

setuptools_scm reads the git repository at build time to automatically determine the version number.