mahtuag
I install Python locally (w/o the OS-level package manager which doesn't have Python 3.5 yet) and would like to install the SciPy stack which depends on a bunch of C libraries only supplied by the Linux distro I am using.
What I'd Like:
Something like npm's package.json or pip's requirements.txt where I can declare the semantically versioned C/C++ dependencies of a project; doing conan install should fetch and install those dependencies so that pip can (as a future feature) invoke this before installing the SciPy stack and not pause a dozen times complaining about a missing dev dependency.
Does conan solve this problem ? If no, what alternatives do I have ?
Depending on OS-supplied libraries is a royal pain because they are almost always outdated.
I'm all for one idiomatic package manager per language/platform (as it is today for a lot of recent ones) which simplifies dependency management significantly.
I tried using gRPC with Go before having to abandon the project for reasons outside my control. Looking forward to using it once again and this time take it to production. The only trouble I had was with the documentation which was scarce.
Anyway, here are some comments on how to improve things with gRPC:
1. A dedicated mini-site for each supported language. This http://www.grpc.io/docs/guides/auth.html is really confusing to read due to the cocktail of languages. All examples need to be in all languages and the user should be able to choose which language to view documentation for.
2. http://www.grpc.io/docs/guides/error.html needs to be populated. Right now I use a custom error code enum w/ 0 as SUCCESS so that my downstream consumers (app developers) get a descriptive identifier. I don't even know if there is anything else I should be aware of that gRPC offers to work with errors.
3. A how-to on setting (on a client) and accessing (on a server) custom HTTP headers in gRPC. This is needed for reading the Authorization header during authentication for example. Another example is setting the From header (email of user) and using this to enable persistent sessions. I appreciate the docs covering these two specific examples as they are rather common.
4. A simple guide on how to manually make an application speak the gRPC protocol - both as a client and as a server. Helpful for those who want to integrate other languages w/ gRPC enabled languages. Endgame is they can speak the wire protocol and understand the conventions just enough to quickly write a working client/server for their app. Great if this example uses JavaScript (most people have to learn it anyway due to the browser).
5. RPCs with multiple messages as arguments in input and/or output. All examples have SomeServiceRequest and SomeServiceResponse messages for SomeService RPC giving the impression that all RPCs are single argument in the .proto file. This isn't stated explicitly anywhere creating an ambiguity.
6. Move to Discourse from Google Groups. Much easier to use and would let us organize the discussions better. Also use this to power comments on the gRPC website for each page. I can see this step alone helping the community aspect of gRPC immensely.
7. Create a visual gRPC explorer. Ideally this should be a simple HTML/CSS/JavaScript static page running on browsers that support HTTP/2 and making it would be a good way to start supporting gRPC on the browser (refer Point 5 above).