Description
Bug Description
tl;dr: When building code from an sdist that has a workspace Cargo.toml
in the root with default-members
and some default-members
are not bundled the install will fail.
Either of these options would probably fix that:
- Remove the whole
default-members
list inrewrite_cargo_toml
. No default members: all listed members are the default - Filter
default-members
the same way as done formembers
.
A bit more context that lead me to this:
We're using UniFFI and maturin to build all of that.
We have a rather involved build process targeting several different platforms, only one of which is Python.
Up until now we did publish source distributions (sdist), but never actually tested them.
Turns out they were broken because no uniffi-bindgen
is around.
We use a bundled uniffi-bindgen
, with some extra changes, so using pip install uniffi-bindgen
leads to other problems.
So I now went ahead and added this to our pyproject.toml
:
include = [{ path = "tools/embedded-uniffi-bindgen/**/*", format = "sdist" }]
and also a dependency to the crate maturin builds:
[dev-dependencies.uniffi-bindgen]
path = "../../tools/embedded-uniffi-bindgen"
The latter is necessary to force maturin
to consider the top-level Cargo.toml
the workspace root.
Otherwise no root package is found.
With another package listed in default-members
that is NOT part of the source distribution pip install ./package*.tar.z
will fail with something like:
error: package `/tmp/pip-req-build-8nv3y915/glean-core/rlb` is listed in workspace’s default-members but is not a member.
Right now the only way to work around that is to remove glean-core/rlb
from the default-members
list.
I'm doing that for now in mozilla/glean#2801
Your maturin version (maturin --version
)
1.5.1
Your Python version (python -V
)
3.12.0
Your pip version (pip -V
)
24.0
What bindings you're using
uniffi
Does cargo build
work?
- Yes, it works
If on windows, have you checked that you aren't accidentally using unix path (those with the forward slash /
)?
- Yes