Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Explicit proto import search path #40
This tries to address #39.
The new function is more consistent with the behavior of
With the previous function, the working dir was always added to the search path, and the
Open to suggestions on naming the new function.
referenced this pull request
Jan 18, 2018
I'd like a self contained example of the problem we are solving before introducing a '2' function. I had a very clean way to do this previously, but I don't remember if I had local employer-specific wrappers to do this. I do feel there is a slightly simpler solution. Can the submitter add a small self-contained unit test that requires this function (and has two .proto files in different subduers of unitTests). If I can't find a better/cleaner way to get it to work, then yes we should just add this. - Murray…
On Thu, Jan 18, 2018 at 5:19 AM, Dirk Eddelbuettel ***@***.*** > wrote: That doesn't look unreasonable, and well localized. @murraystokely <https://github.com/murraystokely> any views? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#40 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEwu7ZnK-R4YhSco_xCQG1QUBFapo0ZMks5tL0TKgaJpZM4RiiaY> .
I tried to write unit tests but it is impossible to get a clean environment in the unit test setup. Every call to readProtoFiles adds directories to the search path that are never removed.
As one use case of where the existing function gets tricky, I added a new proto file to a subdirectory in the unit tests in siddharthab@d780a38 and wrote unit tests using the new function. While there could be ways to make it work with the old function (mostly by changing working dir), I suspect they are not clean and intuitive. As of now, even the existing unit tests are failing because of the addition of this new import.
A rare use case that is impossible to make work with the existing function is when two directories have cyclical dependencies but are independent components in the search path. See siddharthab@0f5e650 for an example. This case can be easily handled with
Another advantage of the new function is that you will no longer require to retain the search path, and will be able to clear it after every call. Retaining the search path is also bug-prone when multiple files have same basename because the user will not realize that the importer is using a file from a previously added directory and not the file that he intends.
If you want, I can write up some more detailed test scripts so that we get a clean environment at the start of each script. Short of that, we will have to introduce utility methods to clear state, etc.
I would have liked to hear @murraystokely on this, but looks like I won't.
As the patch cleanly extends the API and makes no changes to existing code, I see no harm. You should examples of existing code not allowing you to do what you wanted, so on balance this is a net benefit.
Thanks for the PR. I'll merge it now,