Modernize development workflow and packaging with UV

[Binbasri-in]

This PR updates the project’s development and CI workflow to use UV for packaging, dependency management, testing, and linting.

• Added a new pyproject-based project configuration and kept packaging metadata there
• Simplified setup.py to rely on the new pyproject configuration
• Updated the README and docs instructions to use UV for local setup, testing, and docs builds
• Adjusted the docs build command in the Sphinx Makefile to use UV
• Changed the client behavior for lowercase VTN IDs from raising an exception to logging at debug level
• Switched CI from pip-based setup to UV-based dependency installation and test execution
• Expanded the GitHub Actions test matrix to cover Python 3.10, 3.11, and 3.12
• Updated GitHub Actions workflow steps to newer action versions

[axmsoftware]

Thanks @Binbasri-in for adding UV support please review Check errors. Feel free to consult CoPilot to address. Thanks!

[Binbasri-in]

yes I updated it now, should run now, let's see if it works this time

[Binbasri-in]

Also, should I create it in a separate branch? this pull request is on main branch

[axmsoftware]

@Binbasri-in Different errors, see from CoPilot:
Failure root cause

• Tests fail during import because signxml's processor accesses ec.SECT163K1:
  AttributeError: module 'cryptography.hazmat.primitives.asymmetric.ec' has no attribute 'SECT163K1'
• Your pyproject currently pins signxml==3.2.1 for Python < 3.12 (line 15). The CI environment (Python 3.8) therefore installs signxml 3.2.1 which expects EC curve attributes that are not present in the installed cryptography release. That makes test collection fail immediately.

Two safe fixes (recommended order)

1. Recommended: stop installing the old signxml on older Pythons — use a modern signxml that is compatible with recent cryptography

• Change pyproject.toml to require signxml>=4.5.1 for all Python versions (remove the conditional pin to 3.2.1). This ensures signxml's code path that uses supported curve APIs is used across CI interpreters.

Patch (pyproject.toml) — replace the existing signxml lines:

• Current fragment:
  "signxml==3.2.1; python_version < '3.12'",
  "signxml>=4.5.1,<5.0.0; python_version >= '3.12'",
• Replace with:
  "signxml>=4.5.1,<5.0.0",

Example diff:
--- a/pyproject.toml
+++ b/pyproject.toml
@@

• "signxml==3.2.1; python_version < '3.12'",
• "signxml>=4.5.1,<5.0.0; python_version >= '3.12'",

• "signxml>=4.5.1,<5.0.0",

• Commit message suggestion: "CI: use signxml >= 4.5.1 for all python versions to avoid cryptography API mismatch"
• Local verification:
  • pip install -e .
  • pip install "signxml>=4.5.1,<5.0.0"
  • pytest

Why this is preferred

• Upgrading signxml avoids depending on older, less-maintained code paths and makes the package compatible with current cryptography releases used by CI runners.
• Minimal change and addresses the real incompatibility rather than forcing older cryptography versions.

2. Alternative/workaround: pin cryptography to a version compatible with signxml 3.2.1

• If you must keep signxml==3.2.1 for other compatibility reasons, add a cryptography upper-bound that provides the required EC attributes (for example pin cryptography to the last known-compatible major version). This is less future-proof and forces CI to use older cryptography builds.

Example (pyproject.toml):

• Add dependency e.g.:
  "cryptography<40.0.0",

Note: I could not determine the exact last cryptography version that still exposed SECT163K1 in this repository snapshot; the safer, lower-maintenance approach is to upgrade signxml.

Extra verification suggestions

• After changing dependencies, update your lockfile (if you use one) and re-run the CI. The error occurs at import time — fixing the dependency and re-running tests should resolve the failures.
• If you want to be extra safe, run tests under the same Python versions used by your CI (3.8 in the failing run) locally or in a matrix.

If you want I can prepare a small PR patch for pyproject.toml with the exact change shown above.

[Binbasri-in]

okay, I will check again. I will test the workflow locally and make sure it passes before requesting review again. thanks

[axmsoftware]

@Binbasri-in separate branch helps

[Binbasri-in]

I just removed support for Python 3.7 and 3.8, since they are very old.

If we must keep them, then I will try to pin the dependencies that cause the problems