I was just checking the build times from your github repo by running cargo build. If I used it in a project it would be multi-language and require linking against native code through a C shim. It would be great if that was provided and had a stable ABI + .so for the rust code that I could install through a .deb or .rpm instead of building through cargo.
> Though we are pretty lean on dependencies, and I would expect most projects using oso would be using serde anyway.
It would be great if `serde` was opt-in through cargo features, which is pretty common in the Rust ecosystem. While your manifests are small there's still quite a bit getting pulled in. Might want to inspect the dependency graph to see if there's anything excessive or some features that can be non-defaulted.
> That being said those times you're seeing seem very long, even for Rust!
Not in my experience. This was a clean debug build. It's not that uncommon on CI runners to have much longer times than developer machines (MacOS CI runners are especially bad about this, and also cost a lot more money). That's why I do profiling on a weaker one when evaluating build times. Incremental builds are faster, they're also harder to orchestrate.
Not trying to be overly critical, just trying to give a view! Compiling on other people's machines is expensive, a good way for me to buy into something like this instead of doing it myself (which is how I'm doing it right now!) is to reduce the dependency tree and make building stupid fast/easy.
> It would be great if that was provided and had a stable ABI + .so for the rust code that I could install through a .deb or .rpm instead of building through cargo.
This would be a great option. That's effectively how our build pipeline works anyway - we compile the polar-c-api [1] crate to a dynamic lib and embed in each language. If we made this available through package managers, we could also provide an alternative installation for, e.g. Python that didn't even need to use the precompiled wheel.
> It would be great if `serde` was opt-in through cargo features,
We rely on this for the FFI, since we pass events/messages back and forth as JSON. We _could_ make it opt-in for people using it in Rust projects though. Would that work for your use case?
Running our test suite [2] takes about 9 minutes. 4 of which is running (a) the pure Rust tests, (b) compiling the C library and running Python, Ruby, and Java tests, (c) building the WASM library and running Nodejs tests.
That's why I'm a little surprised by the time. You're right though, I didn't factor in the slowdown for the macos builds.
> Not trying to be overly critical, just trying to give a view! Compiling on other people's machines is expensive, a good way for me to buy into something like this instead of doing it myself (which is how I'm doing it right now!) is to reduce the dependency tree and make building stupid fast/easy.
Thank you! I appreciate the feedback. We did go out of our way to make it as easy as possible to install from whatever language package manager (e.g. pip install oso will take seconds). We weren't anticipating people would want to compile it themselves from scratch, so it's a helpful perspective to get.
> Though we are pretty lean on dependencies, and I would expect most projects using oso would be using serde anyway.
It would be great if `serde` was opt-in through cargo features, which is pretty common in the Rust ecosystem. While your manifests are small there's still quite a bit getting pulled in. Might want to inspect the dependency graph to see if there's anything excessive or some features that can be non-defaulted.
> That being said those times you're seeing seem very long, even for Rust!
Not in my experience. This was a clean debug build. It's not that uncommon on CI runners to have much longer times than developer machines (MacOS CI runners are especially bad about this, and also cost a lot more money). That's why I do profiling on a weaker one when evaluating build times. Incremental builds are faster, they're also harder to orchestrate.
Not trying to be overly critical, just trying to give a view! Compiling on other people's machines is expensive, a good way for me to buy into something like this instead of doing it myself (which is how I'm doing it right now!) is to reduce the dependency tree and make building stupid fast/easy.