I'd like to bring up the issue of peer dependencies in Boost, taking Capy's review as an occasion. Running boostdep --brief capy yields: # Primary dependencies asio # Secondary dependencies align assert # and half of Boost, omitted for brevity This is not a hard dependency - Asio is included in an optional header (capy/buffers/asio.hpp) to facilitate integration. I think this is the right choice, but we lack a way to represent this. Every Boost library depending on Capy and using boostdep will now install Asio and half of Boost (when they likely don't need it). I don't know if this has implications for package managers or not (the b2 people probably know the answer). What's everyone's opinion on this? Should we try to do something to represent the concept of "peer dependency"? (maybe a field in meta.json?) Best, Ruben.