Make rules_swift work with virtual import directories. #298
Conversation
This is necessary for the rule set to work with `--incompatible_generated_protos_in_virtual_imports` (and also with `proto_library` rules with `strip_import_prefix` / `import_prefix`)
|
From the bazel issue, I thought the right way of doing this was going to be using the root from the provider and not hardcoding things? |
|
Do I understand correctly that I meticulously told you how to do things the right way then I did them the wrong way anyway? I'm talented like that... Fixed, PTAL. |
|
I'd be happy to, but how do I know if I succeeded? The tests pass with this change, too. |
This is one of the problems trying to write tests for rules/bazel. You need a custom workspace with another repo reference that uses the rules. They are pretty hard to set up, so most rules sets don't seem to have them. |
|
So what do I do? Is there any prior art as to what needs to work? (I thought |
|
Updated the above places and checked whether rules work when imported from a remote repository and with generated |
| @@ -88,7 +91,7 @@ def register_module_mapping_write_action(name, actions, module_mappings): | |||
|
|
|||
| return mapping_file | |||
|
|
|||
| def _generated_file_path(name, extension_fragment, proto_file = None): | |||
| def _generated_file_path(name, extension_fragment, proto_source_root, proto_file = None): | |||
| """Returns the short path of a generated `.swift` file corresponding to a `.proto` file. | |||
|
|
|||
| The returned workspace-relative path should be used to declare output files so that they are | |||
There was a problem hiding this comment.
Is this part still true, or is the output path now slightly different since it might not have some the the original workspace relative info?
There was a problem hiding this comment.
My understanding is that this is still true -- the format is PACKAGE/NAME.protoc_gen_EXTENSION_swift/IMPORT_PATH.<something>, to which all of this is true. Except that the path now contains the import path and not the workspace-relative path of the source file.
| @@ -251,3 +251,20 @@ def workspace_relative_path(file): | |||
| """ | |||
There was a problem hiding this comment.
Is anything left using workspace_relative_path or should it be made private to this file?
There was a problem hiding this comment.
You cannot know that -- anyone can load() this file and use this function from it. If you wish, I can remove it, but be aware that it's a potential incompatible change.
There was a problem hiding this comment.
You cannot know that -- anyone can
load()s this file and use this function from it. If you wish, I can remove it, but be aware that it's a potential incompatible change.
Actually, it is in an internal directory, so we're fine breaking folks that directly tried to use it. It just needs to be not used by anything else within rules_swift. The directory naming is all we can do until bazel has visibility for bzl files.
PiperOrigin-RevId: 266443442
PiperOrigin-RevId: 266443442
This is necessary for the rule set to work with
--incompatible_generated_protos_in_virtual_imports(and also withproto_libraryrules withstrip_import_prefix/import_prefix)