The qcs-api-client-common project uses the pyo3_linter that lives in the rigetti-pyo3 repository. That dependency is specified in the pyproject.toml like this:
[project.optional-dependencies]
dev = [
"pyo3_linter @ git+https://github.com/rigetti/rigetti-pyo3.git@feat-pyo3-linter#subdirectory=pyo3_linter",
# other dependencies...
]PyPI does not allow git-based dependencies like that, so publication fails.
On the one hand, we could publish that package to PyPI to enable this, but it's really quite specific to how rigetti handles its bindings.
Instead, I'd argue that optional-dependencies are the wrong place for dev dependencies; since they aren't meant to enable additional features, they really belong to the domain of developer tooling (in this case uv). For example, quil-rs's pyproject.toml specifies these according to how poetry handles dev dependencies:
[tool.poetry.group.dev]
optional = true
[tool.poetry.group.dev.dependencies]
pyo3_linter = { git = "https://github.com/rigetti/rigetti-pyo3.git", rev = "feat-pyo3-linter", subdirectory = "pyo3_linter" }
# other dependencies...uv has it's own flavor of the same, and I think we should use that instead.
The
qcs-api-client-commonproject uses thepyo3_linterthat lives in therigetti-pyo3repository. That dependency is specified in thepyproject.tomllike this:PyPI does not allow
git-based dependencies like that, so publication fails.On the one hand, we could publish that package to PyPI to enable this, but it's really quite specific to how
rigettihandles its bindings.Instead, I'd argue that
optional-dependenciesare the wrong place fordevdependencies; since they aren't meant to enable additional features, they really belong to the domain of developer tooling (in this caseuv). For example,quil-rs'spyproject.tomlspecifies these according to howpoetryhandlesdevdependencies:uvhas it's own flavor of the same, and I think we should use that instead.