Migrate dependency management to uv (closes #38)

[aviv1ron1]

This PR switches the project from pip/venv to uv for dependency management.

What changed:

• pyproject.toml — added missing [tool.uv] conflict declarations for the tutorials extra (which transitively depends on vllm), fixing uv lock resolution
• uv.lock — universal lockfile for all non-conflicting extras (277 packages); covers vllm and vllm20 separately via the existing conflict declarations
• README.md — replaced pip/venv Quick Start install section with uv sync commands, added model pre-download tip using hf_transfer, fixed Python badge (3.9+ → 3.10+)
• CONTRIBUTING.md + docs/GIT_WORKFLOW.md — updated dev setup and test commands to use uv sync --extra dev and uv run pytest
• CLAUDE.md — updated installation section to uv commands
• tutorials/PREREQUISITES.md + tutorials/guides/ — replaced all pip install references with uv sync / uv pip install

CUDA note: the vllm/vllm20 extra split already handles the CUDA 12 vs 13 version requirement — the lockfile is universal and does not tie to a specific CUDA environment.

[aviv1ron1]

note: no need to change the tutorial notebooks code, since notebooks do not use uv. the notebooks will continue using pip install as currently

[antonpibm]

Is there a better way to handle the conflicts? see my question in the main discussion regarding that

[antonpibm]

One unique aspect of granite-switch is the fact that it's an infra library and should work with different environments.
Environments carry a lot of inherited dependencies such as the torch versions, which in turn limit/affect the version of packages we can install, one such example is the support of vllm 0.20.0 which is supported by Granite-Switch but causes a lot of compatibility problems on older environments.
This raises few points we should address:

1. Where did you build the lock file?
2. We should run the full test suite with dependencies built from this lock file on one (preferably two) different computation environments
3. We can potentially manage the dependency versions with uv groups, where vllm 0.19.1 suite will be the default and the other setups will be possible

[aviv1ron1]

One unique aspect of granite-switch is the fact that it's an infra library and should work with different environments. Environments carry a lot of inherited dependencies such as the torch versions, which in turn limit/affect the version of packages we can install, one such example is the support of vllm 0.20.0 which is supported by Granite-Switch but causes a lot of compatibility problems on older environments. This raises few points we should address:

1. Where did you build the lock file?
2. We should run the full test suite with dependencies built from this lock file on one (preferably two) different computation environments
3. We can potentially manage the dependency versions with uv groups, where vllm 0.19.1 suite will be the default and the other setups will be possible

just tested the uv branch on CCC and it worked out of the box. as a matter of fact the non uv branch did not work for me out of the box on CCC. But i only tried the HF dependency, not vllm.

[aviv1ron1]

One unique aspect of granite-switch is the fact that it's an infra library and should work with different environments. Environments carry a lot of inherited dependencies such as the torch versions, which in turn limit/affect the version of packages we can install, one such example is the support of vllm 0.20.0 which is supported by Granite-Switch but causes a lot of compatibility problems on older environments. This raises few points we should address:

1. Where did you build the lock file?
2. We should run the full test suite with dependencies built from this lock file on one (preferably two) different computation environments
3. We can potentially manage the dependency versions with uv groups, where vllm 0.19.1 suite will be the default and the other setups will be possible

just tested the uv branch on CCC and it worked out of the box. as a matter of fact the non uv branch did not work for me out of the box on CCC. But i only tried the HF dependency, not vllm.

My suggestion is this:

• Keep dev as a group with just pytest and dev tooling — no bundled vllm
• User composes: uv sync --group dev --extra vllm or uv sync --group dev --extra vllm20
• This eliminates dev-vllm20 entirely and reduces conflicts to just one: vllm vs vllm20

So [tool.uv] goes from 6 conflict pairs down to 1:

[dependency-groups]
dev = ["pytest", "granite-switch[hf,compose]"] # no vllm bundled
test = ["pytest", "bitsandbytes", "optimum-quanto"]

[tool.uv]
conflicts = [
[{ extra = "vllm" }, { extra = "vllm20" }],
]