ImportError (google.protobuf) with rdm_test_server.py

[ssilverman]

When I try to run rdm_test_server.py, I get this:

Traceback (most recent call last):
File "/usr/local/bin/rdm_test_server.py", line 38, in
from ola.ClientWrapper import ClientWrapper, SelectServer
File "/usr/local/lib/python2.7/site-packages/ola/ClientWrapper.py", line 28, in
File "/usr/local/lib/python2.7/site-packages/ola/OlaClient.py", line 21, in
File "/usr/local/lib/python2.7/site-packages/ola/rpc/StreamRpcChannel.py", line 20, in
ImportError: No module named google.protobuf

I'm using homebrew to install ola. I've tried reinstalling protobuf and ola, but I get the same error.

System: OSX 10.14.6

[peternewman]

Hi @ssilverman ,

We are having the same issue too, you can see our progress in #1584 .

We're currently doing:
pip install --user protobuf==3.1.0

I think Homebrew have switched to Python 3 only for Protobuf, see #1538 for our progress on that front.

Although did ./configure succeed for you? It may just be a path issue in that case. Could you post your config.log (probably before trying to re-run it).

[ssilverman]

Before I try anything I'll gladly send you the config.log file, but do you know the path of the one you're looking for?

[peternewman]

I don't know specifically, but this looks relevant:
https://apple.stackexchange.com/questions/164525/what-directory-does-homebrew-use-to-build-programs

Other than that, it will likely be in an ola or olad folder if you can find any config.log files on your machine.

[ssilverman]

There's no config.log files that I could find, related to the ola install. After installing ola, however, there's also no configure file. Are you referring to one that comes with a git clone or one that comes with the homebrew install?

[kripton]

@ssilverman : Could you please retry, now that #1605 has been merged? It might have fixed your issue :)

[peternewman]

The RDM tests still don't run under Python 3 due to a few outstanding issues @kripton (xrange being one of the easier ones), so while it may have progressed things and #1655 will have done too, the tests themselves still aren't quite there unfortunately.

[brucelowekamp]

It was never complete, but if you're interested I had some of the work done in the py3-build branch of https://github.com/brucelowekamp/ola.git. There are some imports and other things that I think were necessary beyond the conversion of print and xrange (which is of course the bulk of the changes). I *think* this was the result of running futurize and a couple other tools over the codebase. But I remember there being some unicode stuff in a web module that I couldn't sort out, and there were definitely a few fun things like: ./tools/rdm/TestDefinitions.py: ALL_MODES = ALLOWED_MODES + [3] + range(0x80, 0xe0) that didn't get converted automatically to list(range), and I realized I needed to go back and find them. That was when I narrowed the scope to just the API... Bruce

…

On Wed, Nov 18, 2020 at 7:32 PM Peter Newman ***@***.***> wrote: The RDM tests still don't run under Python 3 due to a few outstanding issues @kripton <https://github.com/kripton> (xrange being one of the easier ones), so while it may have progressed things and #1655 <#1655> will have done too, the tests themselves still aren't quite there unfortunately. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1599 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNHN5KRMPXNZF7RGFFGRG3SQRRSDANCNFSM4JRA4RUQ> .

[peternewman]

Thanks @brucelowekamp . I've also done the print changes in #1685 which I'll merge in as it didn't seem to hurt and seemed to be sufficient to get the compileall stuff to work, although flake8 needs more work, and actually running seems to need more still in some cases.

I went for a slightly different xrange/range solution as in theory it should be more efficient on python2 I think:
https://github.com/OpenLightingProject/ola/pull/1685/files#diff-5b3f8e5df8e5a430e32762b12ed99f846058b721ae6049489f7a6058fbd8f45eR25-R31

[brucelowekamp]

IMHO I would rather change the xranges to range and from builtins import range (or just from future import * so no one needs to think about it) but if you want to leave the xranges in place, then from past.builtins import xrange https://python-future.org/compatible_idioms.html#xrange I think is preferable. IMHO it’s better to use range everywhere b/c you can wind up thinking about xrange and range as different things, which they are in python 2 but not python 3 (unless you from past.builtins import range, but let’s not go there), and it’s better to think about them as the same function and write python 3 code moving forward. Bruce

On Sat, Nov 21, 2020 at 5:29 PM Peter Newman ***@***.***> wrote: Thanks @brucelowekamp <https://github.com/brucelowekamp> . I've also done the print changes in #1685 <#1685> which I'll merge in as it didn't seem to hurt and seemed to be sufficient to get the compileall stuff to work, although flake8 needs more work, and actually running seems to need more still in some cases. I went for a slightly different xrange/range solution as in theory it should be more efficient on python2 I think: https://github.com/OpenLightingProject/ola/pull/1685/files#diff-5b3f8e5df8e5a430e32762b12ed99f846058b721ae6049489f7a6058fbd8f45eR25-R31 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1599 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADNHN5NNSX3GB7DJTFWGOYDSRA5NDANCNFSM4JRA4RUQ> .

-- Sent from my mobile

[peternewman]

IMHO I would rather change the xranges to range and
from builtins import range
(or just from future import * so no one needs to think about it)

I thought theoretically xrange should be more efficient on Python 2 from my understanding? Although how much difference it makes in say the licence check when it's just four values I don't really know.

From what I can tell builtins isn't core either, compared to future, i.e. it's another dependency?

but if you want to leave the xranges in place, then
from past.builtins import xrange
https://python-future.org/compatible_idioms.html#xrange
I think is preferable.

From my, admittedly very quick look, past.builtins appeared to be a separate module which we're then requiring people to have for compatibility.

IMHO it’s better to use range everywhere b/c you can wind up thinking about
xrange and range as different things, which they are in python 2 but not
python 3 (unless you from past.builtins import range, but let’s not go
there), and it’s better to think about them as the same function and write
python 3 code moving forward.

Yeah I can see the logic behind that, I guess I was initially driven by doing it as a quick win on a few bits of code. I certainly haven't made the whole codebase pass yet. If the performance issue is fairly minor then doing a find/replace of xrange to range seems pretty trivial too.