Can't generate proto files without package name

[osztenkurden]

Overall, love the generator, and the only thing that stumbled me was the fact that I can't generate zig files from protos without "package" directive.

Currently working on game data parser, and protos look like this:

import "networkbasetypes.proto";
import "usercmd.proto";

message CSGOInterpolationInfoPB {
	optional int32 src_tick = 1 [default = -1];
	optional int32 dst_tick = 2 [default = -1];
	optional float frac = 3 [default = 0];
}

message CSGOInputHistoryEntryPB {
	optional .CMsgQAngle view_angles = 2;
	optional int32 render_tick_count = 4;
	optional float render_tick_fraction = 5;
	optional int32 player_tick_count = 6;
	optional float player_tick_fraction = 7;
	optional .CSGOInterpolationInfoPB cl_interp = 12;
	optional .CSGOInterpolationInfoPB sv_interp0 = 13;
	optional .CSGOInterpolationInfoPB sv_interp1 = 14;
	optional .CSGOInterpolationInfoPB player_interp = 15;
	optional int32 frame_number = 20;
	optional int32 target_ent_index = 8 [default = -1];
	optional .CMsgVector shoot_position = 3;
	optional .CMsgVector target_head_pos_check = 9;
	optional .CMsgVector target_abs_pos_check = 10;
	optional .CMsgQAngle target_abs_ang_check = 11;
}

...

So, no package name. To make it work, Im adding package name by hand, and then I have to also remove dots from the field types on messages (so optional .CSGOInterpolationInfoPB cl_interp = 12; will become optional CSGOInterpolationInfoPB cl_interp = 12;). I'm trying currently to make it work on the fork of the project, but I'm quite new to zig, so it's not going super fast

[Arwalk]

Hello there, thanks for your interest and issue.

Overall, love the generator, and the only thing that stumbled me was the fact that I can't generate zig files from protos without "package" directive.

I think we inherited this behaviour from the original generator that served as basis of this one. It was a go-based one, and it required packages. I'll take a look into it to know if i can find a workaround about this.

I have to also remove dots from the field types on messages

Looking a the proto language spec :

It would seem that a dot is allowed before a type name, for some reason. It's also allowed for inner messages, i think. I'll have to look into that, and handle at least properly the beginning dot.

Thank you again.

[osztenkurden]

Thanks, ill try tweaking through the weekend and try to make a PR, but I dont think it will be fast

[osztenkurden]

PR #58 created, still WIP, but I'd appreciate veryfing if it doesn't break existing protos

[mochalins]

It would seem that a dot is allowed before a type name, for some reason. It's also allowed for inner messages, i think. I'll have to look into that, and handle at least properly the beginning dot.

A dot before a type name is supposed to represent the root/global package ("outermost scope"). Hopefully this wouldn't be too difficult to normalize. https://protobuf.dev/programming-guides/proto3/#name-resolution

@Arwalk with the removal of Managed types in feature/ziggify, users of zig-protobuf actually don't need an explicit runtime dependency on protobuf.zig; only a transitive dependency is required through each generated .pb.zig's reference to protobuf.zig.

This means, for example, that a Zig package Foo containing foo.proto could have its own dependency on zig-protobuf, and generate foo.pb.zig during its build step. However, consumers of the Foo Zig package may not have zig-protobuf as its own dependency, which means no @import("protobuf"). Instead, consumers may now simply import just the generated foo.pb.zig for direct use.

As we are not guaranteed that end consumers will always have an accessible protobuf import, where should these global namespace proto definitions go? Should we generate a protobuf.pb.zig alongside the foo.pb.zig, that publicly imports all such generated files (e.g. top-level pub const foo = @import("foo.pb.zig")) and also contains these global namespace proto definitions?

Curious to hear any thoughts; hoping to tackle this one soon.

[Arwalk]

I have some comments/suggestions/ideas on this but i'm currently too tired to formulate them properly, just wanted to let you know that i'd prefer if you could wait for them before doing this @mochalins

Thanks again

[Arwalk]

As we are not guaranteed that end consumers will always have an accessible protobuf import, where should these global namespace proto definitions go? Should we generate a protobuf.pb.zig alongside the foo.pb.zig, that publicly imports all such generated files (e.g. top-level pub const foo = @import("foo.pb.zig")) and also contains these global namespace proto definitions?

After reviewing my own ideas and the documentation, i think it could be a good idea to put all the global namespace proto definitions in a "protobuf.pb.zig" file, but i'm not sure if we need to bother with importing the underlying packages. Would it help us solving some importing issues (with proto files importing something that's not in their package but would be hard to reach with @import directive because of its limitations?)

edit: i've been wondering for a while if it wouldn't be nice if RunProtocStep could generate modules on the fly, that could solve a lot of import problems.

[mochalins]

After reviewing my own ideas and the documentation, i think it could be a good idea to put all the global namespace proto definitions in a "protobuf.pb.zig" file, but i'm not sure if we need to bother with importing the underlying packages. Would it help us solving some importing issues (with proto files importing something that's not in their package but would be hard to reach with @import directive because of its limitations?)

Actually, I thought of always publicly importing all underlying .pb.zig files just for consistency; I thought it might be a little strange for protobuf.pb.zig to be generated only when there are global namespace protos, and missing in other cases. However, I don't think it's a big deal; I'll implement the first approach without the imports, and we can see how it feels to use!

edit: i've been wondering for a while if it wouldn't be nice if RunProtocStep could generate modules on the fly, that could solve a lot of import problems.

Hmm... I'm not quite sure what you mean by this. Perhaps I'll be able to understand this better as I work on the first protobuf.pb.zig approach.