Summary
[ci].deploy is a single switch over both publishing paths. On a tag push it emits, together:
Wheel Deploy — pushes the wheel to devpiConan Deploy - Linux / Conan Deploy - Windows — push the Conan packages to the Conan remote
There is no way to keep one and drop the other.
Why it matters
A library whose only consumer is Python has no use for its Conan packages. Nothing links them; they are published on every tag, take up space on a shared remote, and add two jobs to every release pipeline for no benefit.
xmssnap is the concrete case. Python is its sole consumer — the .pyd is the only way to use the library, and no C++ code links it, not even dynamically. Its Conan packages exist purely as a build artifact of producing the wheel.
The reverse pairing is plausible too: a C++-only library with pybind = False still gets a Wheel Deploy job emitted whenever [ci].deploy is on.
Suggestion
Split the flag, keeping [ci].deploy as the master switch so nothing changes by default:
[ci]
deploy = true # unchanged: master switch for the Deploy stage
conan_deploy = false # new, default true
wheel_deploy = true # new, default true
Both new keys default to true, so every existing project renders exactly what it does today. deploy = false continues to drop the whole stage regardless.
A guard is probably worth it for deploy = true with both sub-flags false, which would emit an empty Deploy stage — the same shape as the two guards added in #90 for [ci].linux.
Priority
Low. This is a nice-to-have, not a blocker — publishing unused Conan packages is wasteful but harmless, and xmssnap will ship with deploy = true and simply carry them. Filing it so the decision is recorded rather than rediscovered.
Context
Found while converting xmssnap to Conan 2, alongside the three gaps addressed in #90. Reviewed with @gagelarsen, who asked that this one be tracked as a future feature rather than fixed now.
Summary
[ci].deployis a single switch over both publishing paths. On a tag push it emits, together:Wheel Deploy— pushes the wheel to devpiConan Deploy - Linux/Conan Deploy - Windows— push the Conan packages to the Conan remoteThere is no way to keep one and drop the other.
Why it matters
A library whose only consumer is Python has no use for its Conan packages. Nothing links them; they are published on every tag, take up space on a shared remote, and add two jobs to every release pipeline for no benefit.
xmssnap is the concrete case. Python is its sole consumer — the
.pydis the only way to use the library, and no C++ code links it, not even dynamically. Its Conan packages exist purely as a build artifact of producing the wheel.The reverse pairing is plausible too: a C++-only library with
pybind = Falsestill gets aWheel Deployjob emitted whenever[ci].deployis on.Suggestion
Split the flag, keeping
[ci].deployas the master switch so nothing changes by default:Both new keys default to
true, so every existing project renders exactly what it does today.deploy = falsecontinues to drop the whole stage regardless.A guard is probably worth it for
deploy = truewith both sub-flagsfalse, which would emit an empty Deploy stage — the same shape as the two guards added in #90 for[ci].linux.Priority
Low. This is a nice-to-have, not a blocker — publishing unused Conan packages is wasteful but harmless, and xmssnap will ship with
deploy = trueand simply carry them. Filing it so the decision is recorded rather than rediscovered.Context
Found while converting xmssnap to Conan 2, alongside the three gaps addressed in #90. Reviewed with @gagelarsen, who asked that this one be tracked as a future feature rather than fixed now.