Consider support for Monorepos

[awelzel]

Zeek distributors with very many packages are currently required to maintain packages as individual Git repositories if they want to use zkg.

I've observed PRs being created over 30+ repos in order to do regular package maintenance, common updates to btest.cfg files, updating copying/license files, or doing other common minor modifications. That feels inefficient.

While multi-repos are certainly useful if packages are authored and maintained by different developers or organizations, larger organizations may prefer to place all packages into a single repository in order to streamline and simplify updates across packages. Particular with Zeek's continuing deprecations and new language features, this is likely not uncommon.

Hypothetical, instead of having 30+ PRs to add or change a environment variable to btest.cfg, opening a single PR, updating 30+ btest.cfg files in a single repo is easier to review, approve (and also revert if something goes wrong).

There's no concrete user request here that this ticket is based on, this is mostly personal observation and impression that zkg precludes a monrepo-based workflow.

There's no urgency to change this. If anything, this issue can be a place for users to add their experiences and thoughts on the topic. Maybe there's also a clever workaround with git magic that could be shared here.

[bbannier]

This seems like it could be useful, and is supported by other package managers, e.g.,

• Python:
  • Packages for distribution with Poetry
  • Multiple wheels in a single project with Hatch
• Rust has native support for multiple crates in a project via workspace members

The approach seems to be to mention contained subpackages in the meta (either explicitly or with wildcards), something which should be possible in zkg's meta as well.

The part I have not wrapped my head around is versioning. Currently the only versioning information respected by zkg are Git tags, and having multiple packages in a single repo would force a single, shared version for all packages as well. Unless we find a way to address this, e.g., by making the version explicit in a package's zkg.meta, zkg "monorepos" wouldn't be much different from just having a bunch of unrelated functionality in a single repo which is already possible today.