Consider a "python-grpc" Ubuntu package?

[nathanielmanistaatgoogle]

This is somewhat related to #936 but is a different work item that I'd like to track in a separate issue.

Do we want to publish a "python-grpc" Ubuntu package? @jgeewax the other day suggested to me personally that we should, but I'd like to hear a few other opinions (and perhaps a work estimate) before deciding to put this on the roadmap.

What's the value proposition above-and-beyond having gRPC Python on PyPI?

[nicolasnoble]

I believe we should. Bringing it to a package means we'd have more options for our end users, and it would make the installation process smoother.

In terms of work involved, the biggest challenge and blocker however is OpenSSL. It's against the Debian/Ubuntu rules to have an official package that has an embedded OpenSSL - which is what we're currently doing for building gRPC without a system OpenSSL 1.0.2. So following the dependency tree for a python-grpc package, we need to first get a gRPC package, which itself depends on having OpenSSL 1.0.2 available for Ubuntu.

I tried doing this, and while I got mixed results, I feel nervous about us officially providing OpenSSL. This is a responsibility which isn't really desirable in my opinion. So we'd need to wait for OpenSSL 1.0.2 to be an official Ubuntu package.

Note that right now, it's an official Debian experimental package - so we could get started in that direction.

[ctiller]

@a11r, @jayantkolhe - should this be Beta?

[ctiller]

I think this should be the next thing we do once pip install works properly

[jtattermusch]

@ctiller really? With a one line "pip install grpcio" working well on most platform, I don't think we need this in the near future. Actually, I'd just close this and we can revisit this in 6 months or so.

[LiranLast]

I have opened issue 11255, which was (rightly) closed as a duplicate.

While for python developers deploying on their own server "pip install grpcio" is great, for app developers distributing applications written in python, it's not as good.

We prefer distributing our own applications using apt-get for a few reasons:

• PIP is not installed by default on many Debian distributions, and even Python might not be installed.
• Our customers may not be familiar with PIP, or it may even be against some internal policy.
• Better system level support for init.d and similar configurations.

A Debian package cannot rely on a pip package. It is against Debian policy, and causes many difficulties at install time and runtime.

stdeb (https://pypi.python.org/pypi/stdeb/0.8.5) supposedly makes the conversion very easy. Have you looked at it?

[mehrdada]

We have carefully considered the general question of shipping packages in system repositories and that is not on our current plans and we are not prioritizing this at the moment. Please do consider filing specific issues if this prevents you from using gRPC or severely impacts such usage.

[nathanielmanistaatgoogle]

@LiranLast: we haven't yet looked at it and we're not aware of the absence of a Debian package being meaningfully important to a large number of users (respecting that it's meaningfully important to you!). Can you tell us more about how many users would find this valuable? Also have you tried building the package and distributing it to your customers? If we're not able to do this any time soon, would that be a way forward for you?

[LiranLast]

@nathanielmanistaatgoogle we are in very early product stages, and our current users are in fact Python users. As such for most of them, pip install provides an adequate alternative, but in the next few months that is likely to change.

Some of the alternatives include packaging/building grpc ourselves or moving that component to a platform that would be easier to deploy (possibly go).

[randomshinichi]

@LiranLast Hi, we've also found the need for a python-grpc package for Debian. I was just wondering if you managed to roll your own and host it on a PPA somewhere?

[LiranLast]

@randomshinichi We have decided to settle on pip install for the last few months and provide the customer with a bash file for installation.

We are unhappy with installing a Python product on the customer's servers and are seriously considering porting this product to a native, compiled language.

[nathanielmanistaatgoogle]

@mehrdada is going to be taking another look at this in the coming months.

[mehrdada]

The prime motivator for this revisiting was the inability to utilize epoll from our manylinux1 packages. Since we have figured out a way to work around that (#14041), the upside is minimal and the downside of maintaining an extra distribution mechanism is significant, so I will close this again.