gRFC L65: Additional PyPI Packages for gRPC Python

[Lidi Zheng]

Abstract:

gRPC Python is uploaded as "grpcio" on PyPI, but there is another package named "grpc". Hence, some users are confused. This document proposes to upload additional packages named "grpc" and "grpc-*" to guide users to official packages.

gRFC: https://github.com/lidizheng/proposal/blob/L65-python-package-name/L65-python-package-name.md

PR: https://github.com/grpc/proposal/pull/177

[Kailash Sethuraman]

Have you considered using the name for a new meta-package bundle for related packages?

• grpcio
• grpcio-status
• grpcio-channelz
• grpcio-reflection
• grpcio-health-checking
• 
  

Or even a kitchen sink package that includes grpcio-testing and grpcio-tools. 

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/482e22f0-4044-4f7e-81b9-179f70ac5be5%40googlegroups.com.

[Lidi Zheng]

Richard had an idea that we could create a bundle named `grpcio[protobuf]`, which includes peripheral packages. After all, gRPC team wants to keep the implementation agnostic to codec, so they weren't packed into the main package.

It's a good idea, this gRFC is for package name confusion. For the new bundle package, I can start another proposal.

[Kailash Sethuraman]

To clarify, I am suggesting that you consider solving the package name confusion by using the gRPC name for a meaningful package that does not exist yet. Another positive with this approach is that its intuitive -  "if I type pip install grpc, I expect to get a working gRPC package installed."  You can err this package toward sane defaults and depend on protobuf too - 99% of your users use it with protobuf anyways..

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/8567af8c-0404-40c4-8dcd-d44fa9008c46%40googlegroups.com.

[Richard Belleville]

Kailash,

This idea has been floated in the past. I think there are two levels of value embedded in your proposal. The first is a simple bundle package. No code, just a grpc==1.XX package declaring dependencies on other packages, including:

• grpcio==1.XX
• protobuf==(some version of protobuf we've tested against)
• grpcio-channelz==1.XX
• grpcio-reflection==1.XX
• grpcio-health-checking==1.XX
• grpcio-status==1.XX

That list intentionally omits grpc-testing and grpc-tools, because both of those should be build-time-only dependencies (thought that may change in the future). As far as I can see, the only downside here is download size. Basically everyone is going to be using grpcio and protobuf, but basically no one is going to be using the other packages, based on the code I see trolling Github. You could argue that that's simply because very few people even know these packages exist. Perhaps. But that claim isn't exactly falsifiable.

Even so, downloading a couple of megabytes of Python code that you're not going to use isn't the end of the world, especially when you have the option to download the individual packages you need after doing a little research on the topic.

So, overall, a dependency bundling package seems like a slam dunk.

The second level of value is a package that, in your own words, "err(s) ... toward sane defaults". I assume this means things like automatically adding a reflection servicer, health servicer, channelz server, etc. We wrap gRPC Python at Google internally to do this sort of thing by default. But there are some problems with this. Suppose a new user instantiates a server not knowing that all of these bells and whistles are activated by default. They're now paying the cost at runtime. Even worse, the reflection server and channelz server could pose a security problem.

There are also API considerations here. If you add new classes/functions to the grpc package, what Python module do you put it under? grpc? That module is already occupied by the code in the grpcio package. That problem isn't insurmountable. But it does mean trouble with name clashes. So we'd have to name the function that gives you a bells-and-whistles server something besides grpc.server, which is already taken. Otherwise, it would constitute an API regression. So now you've got a different function, grpc.bells_and_whistles_server() that no one knows about. It's not the most obvious name, so how likely are people to use it? You've have to rewrite all of the documentation/examples to recommend its use (along with loud disclaimers about when/why not to use it). It's (perhaps) doable, but it's a lot of effort for what (at the moment) seems like a low level of demand.

Finally, it's worth pointing out that the current proposal isn't necessarily the end of the line. It leaves us room to go down either of the above two paths in the future if we see enough demand from the community for it.