Allow passing descriptor_set as bytes instead of a file path

[anuraaga]

Currently, buffa-build allows passing a descriptor_set to use instead of proto files

buffa/buffa-build/src/lib.rs

Line 1640 in ccc9add

pub fn descriptor_set(mut self, path: impl Into<PathBuf>) -> Self {

This is then just read into bytes

buffa/buffa-build/src/lib.rs

Line 1772 in ccc9add

DescriptorSource::Precompiled(path) => std::fs::read(path).map_err(|e| {

It would be great if bytes could be passed directly for when the build script can prepare them, for example using protox. Perhaps changing Precompiled to hold a Vec<u8> and have the parameter accept either a sealed trait that is implemented for both Path and &[u8], or if breaking is ok, just accept the slice only since reading a path (as buffa-build currently does) wouldn't be that hard for a user.

[harshitwandhare]

Precompiled is consumed in three places rather than the two linked above, and the third decides the shape. On ca59251, in buffa-build/src/lib.rs:

• Precompiled(PathBuf), the variant, at :55
• set by descriptor_set() at :1689
• read with std::fs::read at :1829
• the mode check that makes .files() proto-relative names instead of include-stripped paths, at :1859
• println!("cargo:rerun-if-changed={}", path.display()) at :1983-1984

That last one is the reason I would not change Precompiled to hold a Vec<u8>. The path is the build script's change-detection input. Drop it and every existing descriptor_set(path) caller quietly stops rebuilding when their descriptor set changes, which is a correctness regression that produces no compile error and so would not surface during anyone's migration.

A bytes source has no filesystem input to watch, and should not have one. The caller who produced the bytes, protox in your case, is the one who knows what those bytes depend on, and can emit its own rerun-if-changed. So the two sources genuinely differ at :1984, which is an argument for two variants rather than one variant with a widened payload:

enum DescriptorSource {
    Protoc,
    Buf,
    Precompiled(PathBuf),
    PrecompiledBytes(Vec<u8>),
}

with a sibling descriptor_set_bytes(impl Into<Vec<u8>>). PrecompiledBytes joins Precompiled at the :1829 read, since it is already bytes, and must join it at the :1859 .files() branch, because the proto-relative-name expectation is a property of not having run protoc rather than of having read a file. It is then simply absent from the :1973 rerun match.

That needs no breaking change, so your second option's cost disappears.

The sealed trait in your first option has a smaller problem worth naming: descriptor_set takes impl Into<PathBuf> today, so &str, String and PathBuf all compile. A trait covering both paths and bytes has to keep all three working, and String against Vec<u8> is the only pair in that set that separates cleanly. It is doable, but it buys one method name at the cost of inference that currently just works.

Two things I did not check: whether you would want the bytes borrowed rather than owned, and whether PrecompiledBytes should reject an empty slice up front or let the existing decode_from_slice error at :1841 carry it. I would let the decoder report it, since its message already names FileDescriptorSet.

@iainmcgin this is an API-surface addition rather than a fix, so I would rather have your call on the shape than guess at it. If the two-variant version is what you want, I am happy to send it.