chore: add cpu/cu124 extras for PyTorch index selection

[MaleicAcid]

Add cpu/cu124 extras for PyTorch index selection

Summary

Add optional extras (cpu, cu124) that allow users and CI to override which PyTorch index is used, while keeping the default behavior unchanged.

Motivation

CI environments typically cannot install the full CUDA PyTorch stack, which blocks running pyright for type checking. With this change, CI can use uv sync --extra cpu to install a lightweight CPU-only PyTorch and run type checks cleanly.

Behavior

Command	PyTorch version installed
pip install openlrc	Default from PyPI (GPU-enabled on Linux, same as before)
uv sync	Default from PyPI (GPU-enabled on Linux, same as before)
uv sync --extra cpu	CPU-only build from pytorch-cpu index
uv sync --extra cu124	CUDA 12.4 build from pytorch-cu124 index

This is not a breaking change. pip install openlrc and uv sync without extras behave exactly as before.

Downstream usage

If your project depends on openlrc and you want to switch between CPU and GPU PyTorch builds (e.g. CPU for development/CI, GPU for production), map openlrc's extras through your own pyproject.toml:

[project]
dependencies = [
    "openlrc",
]

[project.optional-dependencies]
cpu = ["openlrc[cpu]"]
cu124 = ["openlrc[cu124]"]

[tool.uv]
conflicts = [
    [{ extra = "cpu" }, { extra = "cu124" }],
]

Then select the variant at install time:

uv sync --extra cpu       # development / CI
uv sync --extra cu124     # production with GPU

What changed

• pyproject.toml: added cpu and cu124 optional-dependencies, both listing torch, torchvision, torchaudio (these packages remain in core dependencies as well)
• Added pytorch-cpu index alongside the existing pytorch-cu124 index
• Added [tool.uv] conflicts to prevent both extras from being enabled simultaneously
• Updated [tool.uv.sources] to route each extra to its corresponding PyTorch index
• Updated README installation instructions and added downstream usage guide

[MaleicAcid]

@zh-plus Hi. My original plan was to get proper code checks (pyright, ruff) running in CI before the 1.6.2 release. Seemed straightforward enough — but it turned into a bit of a rabbit hole.

First, I realized the dependency management needed some work. CI runners don't have GPUs, so installing the default GPU-enabled PyTorch would just crash when trying to import torch. That led to the cpu/cu124 extras PR, which lets CI use uv sync --extra cpu to install a lightweight CPU-only PyTorch. That part is working fine now.

But then I hit a wall: deepfilternet. The package hasn't seen a new PyPI release since v0.5.6, and it imports torchaudio.backend.common — a module that was removed in torchaudio 2.6+. So on any recent torchaudio version, import df simply crashes. The fix exists in their GitHub repo but was never published. And with torchaudio itself entering maintenance mode and actively removing APIs, this is only going to get worse over time.

I'd suggest we go ahead and release 1.6.2 as-is without waiting for the CI improvements, since the deepfilternet issue needs a proper discussion. Here are a few directions we could go:

• Pin torchaudio below 2.6 — quick and easy, but it locks users to an older version
• Lazy-import deepfilternet and skip related tests in CI — keeps CI green without changing runtime behavior
• Replace deepfilternet with something else (e.g. noisereduce, which is pure Python and doesn't depend on torchaudio)
  Happy to hear your thoughts on which approach makes the most sense, or if you have other ideas.

[zh-plus]

Thanks for working on this. I agree with the overall direction, but I don't think this is ready to merge yet.

A few things should be fixed first:

1. The lazy-import change in openlrc/preprocess.py needs matching test updates. Right now CI is failing because the existing tests still patch module-level symbols like openlrc.preprocess.save_audio.

2. The README / PR description should be narrowed to what we can actually guarantee. As far as I understand, tool.uv.sources and custom index routing are local uv behaviors, and are not something pip or downstream consumers will automatically inherit from published package metadata. So the pip install openlrc[cpu] and downstream extra-mapping examples likely need to be revised.

3. Please also verify the “default behavior unchanged” claim for uv sync, since this PR seems to move PyTorch index selection behind extras.

More broadly, I agree that deepfilternet is the harder issue here, and I don't want to block the 1.6.2 release on resolving it.

I'm currently looking into possible replacements for deepfilternet, but that needs separate evaluation first, especially around cross-platform support, runtime efficiency, and real denoising quality on actual audio.

[MaleicAcid]

Thanks for working on this. I agree with the overall direction, but I don't think this is ready to merge yet.感谢你们对此工作的贡献。我同意整体方向，但我认为这还不适合合并。

A few things should be fixed first:首先应该修复一些问题："A few things should be fixed first:"}, 这个分支尚未部署。

1. The lazy-import change in openlrc/preprocess.py needs matching test updates. Right now CI is failing because the existing tests still patch module-level symbols like openlrc.preprocess.save_audio.openlrc/preprocess.py中的懒加载更改需要相应的测试更新。目前CI失败是因为现有测试仍然会修补像openlrc.preprocess.save_audio这样的模块级符号。
2. The README / PR description should be narrowed to what we can actually guarantee. As far as I understand, tool.uv.sources and custom index routing are local uv behaviors, and are not something pip or downstream consumers will automatically inherit from published package metadata. So the pip install openlrc[cpu] and downstream extra-mapping examples likely need to be revised.README/PR描述应该缩小到我们能够实际保证的内容。据我了解，tool.uv.sources和自定义索引路由是局部uv行为，不是pip或下游消费者会自动从发布的包元数据继承的内容。因此，pip install openlrc[cpu]和下游额外映射示例可能需要修改。
3. Please also verify the “default behavior unchanged” claim for uv sync, since this PR seems to move PyTorch index selection behind extras.请同时验证“默认行为不变”声明对于uv sync，因为此PR似乎将PyTorch索引选择移到了额外组件之后。

More broadly, I agree that deepfilternet is the harder issue here, and I don't want to block the 1.6.2 release on resolving it.更广泛地说，我同意deepfilternet是这里更困难的问题，我不想在解决它时阻碍1.6.2版本的发布。

I'm currently looking into possible replacements for deepfilternet, but that needs separate evaluation first, especially around cross-platform support, runtime efficiency, and real denoising quality on actual audio.我目前正在研究可能的替代方案，但这需要先进行单独的评估，特别是在跨平台支持、运行效率以及实际音频的去除噪声质量方面。

Could we pin the Torch-related versions and move forward with the 1.6.2 release instead?
We can skip this PR for now and come back to it later.

[zh-plus]

Agreed. I will pin the Torch dependencies and proceed with the 1.6.2 release this afternoon. We can put this PR on hold for now.