dioxus-primitives on crates.io is at 0.0.0, which is the cargo new template
— 884 bytes, a single add(left, right) function and its test. The real library
only exists in this repository.
That makes the crate unusable by anything that itself gets published, because
Cargo removes the git source when packaging and then resolves the version
requirement against the registry:
error: failed to select a version for the requirement `dioxus-primitives = "^0.0.1"`
candidate versions found which didn't match: 0.0.0
location searched: crates.io index
Marking the dependency optional and leaving the feature off does not help — the
requirement is still validated at publish time.
Where this bites
We render motion design videos from JSON, and our desktop editor is built on
Dioxus with dioxus-primitives for slider, tooltip, switch, separator,
select, popover, dialog, color_picker and label, plus
merge_attributes and use_controlled. Pinned at 02801f2.
The editor therefore has to stay a separate, unpublished crate. Because it
depends on our engine crate, our published CLI cannot depend on it back without a
dependency cycle, so the studio subcommand had to be dropped from the released
binary. Users install the CLI from crates.io and build the editor from source
separately.
None of that is a complaint about the components — they work well, which is why
we are stuck on them rather than around them.
The ask
Would you consider publishing 0.0.1 to crates.io, even as a pre-release? A
version that merely exists would let downstream crates depend on it normally. We
are not asking for API stability guarantees at 0.0.x — the version number
already says what it says.
If publishing is blocked on something specific (unpublished dependencies of your
own, naming, or a deliberate decision to stay git-only for now), it would help to
know that too — we would then plan around it rather than wait.
Happy to help with the release plumbing if that is useful.
dioxus-primitiveson crates.io is at0.0.0, which is thecargo newtemplate— 884 bytes, a single
add(left, right)function and its test. The real libraryonly exists in this repository.
That makes the crate unusable by anything that itself gets published, because
Cargo removes the
gitsource when packaging and then resolves the versionrequirement against the registry:
Marking the dependency
optionaland leaving the feature off does not help — therequirement is still validated at publish time.
Where this bites
We render motion design videos from JSON, and our desktop editor is built on
Dioxus with
dioxus-primitivesforslider,tooltip,switch,separator,select,popover,dialog,color_pickerandlabel, plusmerge_attributesanduse_controlled. Pinned at02801f2.The editor therefore has to stay a separate, unpublished crate. Because it
depends on our engine crate, our published CLI cannot depend on it back without a
dependency cycle, so the
studiosubcommand had to be dropped from the releasedbinary. Users install the CLI from crates.io and build the editor from source
separately.
None of that is a complaint about the components — they work well, which is why
we are stuck on them rather than around them.
The ask
Would you consider publishing
0.0.1to crates.io, even as a pre-release? Aversion that merely exists would let downstream crates depend on it normally. We
are not asking for API stability guarantees at
0.0.x— the version numberalready says what it says.
If publishing is blocked on something specific (unpublished dependencies of your
own, naming, or a deliberate decision to stay git-only for now), it would help to
know that too — we would then plan around it rather than wait.
Happy to help with the release plumbing if that is useful.