Skip to content

Unpackaged default-members lead to build failures when using source distributions #2046

Open
@badboy

Description

@badboy

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 in rewrite_cargo_toml. No default members: all listed members are the default
  • Filter default-members the same way as done for members.

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

Steps to Reproduce

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingsdistSource distribution

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions