I was asked if I want to port an old C library to Rust, and while niche it seems like a pretty cool library to have (in case anyone is dabbling with mixmaster/mixminion type networks in Rust). However, the C version has a feature (involving forward error correction) that the client is a little unsure about with regards to ownership and patents. (Because of how old this library is, it makes me suspect there are no patent issues, but that's beside the point).

I asked if I could make the library open source, and they are fine with it as long as the fec support is left out.

Let's say I would ideally like to not have two different repos/projects for this, what mechanisms does rust/cargo have to help allow more code in the repo than in the published crate?

My spitball idea is to have build.rs check for the existence of src/fec.rs and set a cfg parameter if it finds it, and add the src/fec.rs to the exclude list in Cargo.toml.

Anyone know if there are any crates that do anything like this that one can take inspiration from?

I may end up setting up two different repositories, just to lessen the risk of accidental publishing of the fec parts. But I'm curious to know how this could be accomplished with a single repo and how safe from accidental-publishing-of-the-proprietary-parts one can make it.

I think two repos is the way to go, otherwise it is a high risk of accidental publishing. There are just too many cases of this already and once code is out, it is out, no way back.

Feature gate the proprietary part, use your own non-public package repo and all should be fine as long as code compiles/works with or without given feature. But for library to be more useful it would be nice that proprietary part can be replaced by non-proprietary, so when designing that should be taken into account (maybe use generics or what not), otherwise the library might not be as useful as it could be.

You can use include in Cargo.toml to select only files/dirs you want to publish.

cargo package --list to verify that it selects what you want.

You can use .cargo/config.toml to have local settings that don't get published, and there you can set a custom env var or cfg or [patch.crates-io] to disable or substitute some code.

You can also just use a regular Cargo flag that puts unpublished module behind the flag. The published crate will work without the file as long as the Cargo feature isn't enabled. If a mod is disabled, Rust wont look for it. rustfmt might complain, but a) #[rustfmt::skip] solves that too, b) nobody needs to run rustfmt on a published crate.