News for hackers. Stuff that matters.
Re:BloomRPC: GUI Client for GRPC Services by quietbritishjim on Tuesday December 18, 2018 @03:34AM (#18705258)
Great job. I ran this on Windows by building from source, it seemed to work for me. I just had to change a couple of things:

* Activate Python 2 virtual environment (it didn't work with Python 3!)

* Change forward slashes to back slashes in `./node_modules/.bin/electron-rebuild` (I also ran it as a separate command to `yarn install`, not sure whether `&&` would have worked).

* Run `npm start hot-server` (rather than `npm start server-hot` in the instructions).

* Close the Chrome dev tools, which appeared by default.

I must admit I didn't try actually sending a request. Our services are often split into multiple protos with a full relative import (like: import "companyname/project/foo.proto") so you'd need to set the include path for them to work.

Re:BloomRPC: GUI Client for GRPC Services by fenos on Tuesday December 18, 2018 @03:44AM (#18705286)
Fantastic! I've never had a chance on launching the app on windows, I'm glad it worked!

I think you are running the dev mode, that's why the Chrome dev tools appeared :)

The import paths feature will be released soon so stay tuned! In the meantime, you can temporarily place the imported protos close to the one you want to use

Ty

Re:BloomRPC: GUI Client for GRPC Services by quietbritishjim on Tuesday December 18, 2018 @08:11AM (#18706173)
Sorry I didn't call this out more clearly, but I think the server-hot vs hot-server thing is a typo in the readme that's wrong on any platform.

Looking forward to include path support. I tried flattening my protos into one directory, updated all their `import` directives and gave it a go, and it works great, thanks! Both client and server running on Windows. My protos use a well known type (google.protobuf.Duration) and I was particularly impressed that it worked without me having to copy in the proto file for that.

I'm sure you already know this, but just in case: Include paths don't just help with proto files scattered across different directories, they also allow part of the path to be part of the canonical name of the proto. [1, 2] For example, if you have these files:

    /
        src/
            xyz/
                foo.proto   # Contains: import "xyz/bar.proto"
                bar.proto
Then you need -I/src (or similar) because if you run protoc from within /src/xyz/ without -I then it's like you specified -I/src/xyz, and then foo.proto can't find bar.proto (because it looks for /src/xyz/xyz/bar.proto). Using relative paths like this is useful because you can have proto files with the same file name (like "config.proto") so long as their full canonical name is different, and because generated files are output into corresponding subdirectories (which is especially useful in Python where the subdirectory indicates the package name).

[1] https://stackoverflow.com/questions/18735609/the-path-in-pro...

[2] https://github.com/protocolbuffers/protobuf/issues/723#issue...