Handling of default-members field in Cargo.toml

[weiji14]

Hi @gadomski,

I'm working on packaging stacrs on PyPI for conda-forge, and am encountering an issue when running cargo-bundle-licenses (see details at conda-forge/staged-recipes#28293 (comment)). It seems that what is packaged in the sdist ("crates/api", "crates/core", "crates/extensions") is less than what is listed under default-members field

Specifically, here's what's in the Cargo.toml file:

Version from tag python-v0.2.2:

stac-rs/Cargo.toml

Lines 13 to 18 in d13c0f4

	default-members = [
	"crates/api",
	"crates/cli",
	"crates/core",
	"crates/extensions",
	]

More recent version on main, commit bc62c87 has more than four:

stac-rs/Cargo.toml

Lines 15 to 22 in bc62c87

	default-members = [
	"crates/api",
	"crates/cli",
	"crates/core",
	"crates/derive",
	"crates/extensions",
	"crates/types",
	]

I'm aware that crates/cli is separately packaged at https://pypi.org/project/stacrs-cli/, so it probably won't make sense to include crates/cli in the stacrs PyPI package. Not sure if it would be ok to remove crate/cli from default-members, or if this would need to be handled on maturin itself (PyO3/maturin#2046)?

[gadomski]

🤔 thanks for flagging @weiji14. It looks like it should be as simple as removing extensions and cli from default-members, but that feels awkward — I should be able to have whatever I want in my workspace-level Cargo.toml and not worry about what maturin thinks.

There's a couple of other slightly-awkward things about including stacrs (Python) in the same monorepo as all the Rust crates — e.g. as currently configured, I can release a new stacrs version from unreleased Rust code. That was nice during active initial development, but now that folks are Actually Using stacrs I think should tighten things up.

All that to say, I think I'm going to move stacrs to its own repo and release v0.2.3 from there, which should clean up your issue (and many others). Standby.

[gadomski]

@weiji14 just released https://pypi.org/project/stacrs/0.3.0/, and was able to build from the sdist, so hopefully you're good to go 🤞🏼. Please re-open if that's not the case!

[weiji14]

Yep, the initial issue with cargo-bundle-licenses appears to be gone now with stacrs=0.3.0. Thanks for migrating all the code over to https://github.com/gadomski/stacrs!

There's still some build errors I need to fix at conda-forge/staged-recipes#28293, but they seem to be related to compiling libduckdb-sys, so I'll try and figure that out separately.