Possibly separate dependency roots from dependency definitions

[kriswuollett]

It seems like transitive and prune options are confusing in #100. I am also not sure that the use case of merely being an implementer of third party protos is supported as discovered in #138. So this issue is a possible feature request of specifying the dependency roots at a top level instead of in the repos.

To avoid any confusion I think it may be possible to just provide dependency roots from the combination of a list of fully qualified identifiers and a list of file paths for which each file contains its set of symbols.

The requirement for symbols is necessary if your system could support any number of messages that are opaquely wrapped inside Any protos...

Basically the config file could look like this:

name = "corp"
include_protos = ["grpc/health/v1/health.proto"]
include_symbols = ["envoy.service.ratelimit.v3.Authorization"]

[envoy]
url = "github.com/envoyproxy/envoy"
revision = "72d653e2540cc5f77e2acdc1c9a57a10263d74dc"
protocol = "https"
content_roots = ["api"]

[grpc]
url = "github.com/grpc/grpc"
# v1.64.0
revision = "b8a04acbbf18fd1c805e5d53d62ed9fa4721a4d1"
protocol = "https"
content_roots = ["src/proto"]

And trying to run fetch should fail until I also specify this for example, a dependency of envoy:

[udpa]
url = "github.com/cncf/udpa"
revision = "c52dc94e7fbe6449d8465faaeda22c76ca62d4ff"
protocol = "https"

[rtimush]

This was improved in 0.1.19, both the behavior and the documentation.

Now if you have a protofetch.toml like this:

name = "corp"

[envoy]
url = "github.com/envoyproxy/envoy"
revision = "72d653e2540cc5f77e2acdc1c9a57a10263d74dc"
content_roots = ["api"]
prune = true

you get everything from api, the tree of included files, and warnings for everything that was not found (like udpa).

As for the dependency roots, with pruning enabled you can specify then as allow_policies. I agree that this is a bit confusing, but that's more or less how it used to work. Changing this or introducing a new field would be a breaking change for the protofetch.toml format, which is something we are not ready for yet.

Regarding "include_symbols" — currently protofetch only works on files, not on individual messages. It is a valid use-case to consider, but I think in most cases file-level filtering is good enough.