What about non-monorepos? At my company we have quite a few large-ish projects (consisting of ~5 published artifacts, LoC doesn't matter for my question, but maybe 100k per project?), but the problem is that we want different organizations to have access to different subsets of our projects... so we don't have a mono-repo?

It it possible to do some sort of conglomeration where we could bazel-all-the-things and still publish separate artifacts (jar's, deb's, etc.) for different purposes?

You could import each thing as `http_archive`s or `git_repository` or `local_repository`s and use visibility to manage what projects are allowed to use what

Just trying to understand... so we would have ~5 (going by my original example figure) Bazel builds and then use "imports of published things" to have projects that depend on each other work?

You would have 5 workspaces. How they work together is sort of up to you.

If you use `local_repository`, then you can link whatever's checked out from version control together. This can be dangerous since there's nothing that enforces what version of what works with what, but it's helpful for example, if you want to beta test a new version of a ruleset in a workspace that consumes it.

If you want to be strict about publishing artifacts and versioning, then `http_archive` is the way to go. You can choose your publishing schedule and other workspaces can independently manage which versions of the published artifacts they want to use.

`git_repository` is a middle ground if you don't want the hassle of publishing versioned artifacts, since it lets each workspace reference specific commit SHAs for the things they import.

Thanks. Things may have changed since the last time I investigated Bazel -- I'll read up on this stuff.

I'm actually currently leaning towards something like Nix or Guix just because it really encompasses everything...