Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add dart_package option #298

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

sigurdm
Copy link
Collaborator

@sigurdm sigurdm commented Sep 27, 2019

Should fix: #295

@sigurdm
Copy link
Collaborator Author

sigurdm commented Sep 27, 2019

I'm not entirely sure that this is good enough.
If you generate the protobuf code into a subdirectory of a package (like lib/generated) the dart_package annotation would have to look like

option (dart_options.dart_package) = "foo/generated";

Copy link
Member

@szakarias szakarias left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should add a CHANGELOG entry and increase the package version. And we should maybe discuss the name of the option, but otherwise LGTM.


FileGenerator(this.descriptor, this.options)
: protoFileUri = calculateUri(descriptor) {
// if (protoFileUri.isAbsolute) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove?

@domesticmouse
Copy link
Member

Sigurd, dartfmt --fix -w .?

if (descriptor.options.hasExtension(Dart_options.dartPackage)) {
String dartPackage =
descriptor.options.getExtension(Dart_options.dartPackage);
return Uri(scheme: 'package', path: '${dartPackage}/${descriptor.name}');
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @sigurdm I've been having a look at this, and I think this should be:

return Uri(scheme: 'package', path: '${dartPackage}/${path.basename(descriptor.name)}');

descriptor.name returns the full path of the proto file.

In my project the proto root is not the same as the package directory, so I get something like:

dartPackage: "foo/bar"
descriptor.name: "bar/baz.proto"

Combining them together gives "foo/bar/bar/baz.proto" when it should be "foo/bar/baz.proto".

I believe it would be better to ignore the path from the descriptor because the dart package name should always point directly to the directory that contains the dart source file. Right?

Copy link
Collaborator Author

@sigurdm sigurdm Nov 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the dart package should not have slashes. It should just be a single name (the name of the package where the proto belongs)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ooh interesting... That would be tricky in my project... I have one directory structure with several dart packages, and they all share a common proto root.

Copy link

@dave dave Nov 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah it seems like an unnecessary restriction that your proto file structure should be the same as your dart package structure. Let me explain my project structure:

+ project root
  + server (go packages)
    + main 
    + repo1
    + repo2
    + ...
    + tests (go tests)
  + lib (main dart package)
  + repositories (other dart packages)
    + repo1
    + repo2
    + ...
  + proto (proto root)
    + main (proto files for main)
    + repo1 (proto files for repo1)
    + repo2 (proto files for repo2)
    + ...
  + test (dart tests)

It's convenient to have the proto files all in the same directory structure, but the file structure of the Dart packages doesn't match this. I'm trying to ensure my proto files stay platform independent, so I don't really want to rearrange my proto files to match my Dart directory structure. Nor do I really want to have a separate proto root for each package.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it makes sense to have one proto-root per package, if the protos truly belongs in that package. (At least the generated files have to be moved into lib/ of that package.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK I'll have a go at rearranging my project / protoc commands. I'll let you know how I get on!

@fzyzcjy
Copy link
Contributor

fzyzcjy commented Jul 31, 2022

👀

@oklimberg
Copy link

Any plans for the missing review?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Import Protobuf types from other packages
7 participants