Repository navigation
PyPI installation lacks __init__.py in top-level google directory #713
Description
This is a weird one, but I couldn't import google.protobuf for a while because the PyPI installation didn't include an init.py file in the top-level google directory. Doing a reinstall produced the same results; the top-level google directory still lacked an init.py file.
By looking at this repo, I would expect to see it there. Perhaps you're doing something in the setup.py that is stripping it out unintentionally?
Activity
dano commentedon Aug 20, 2015
setup.py installs the "google" package as a setuptools namespace package, which means it gets installed without an
__init__.py.destijl commentedon Oct 26, 2015
+1 on getting this fixed. It's a common enough problem that there is a stack overflow answer:
http://stackoverflow.com/questions/13862562/google-protocol-buffers-not-found-when-trying-to-freeze-python-app
And I've had to work around this in three different build scripts, e.g:
https://github.com/google/grr/blob/master/vagrant/install_linux.sh#L166
haberman commentedon Oct 26, 2015
A PR would be most welcome! None of us are Python packaging experts, so fixing this ourselves often requires a fair amount of background research first. If anyone has a simple fix, I'm all ears.
xfxyjwf commentedon Jan 21, 2016
Seems related to: #1153
craigcitro commentedon Jan 26, 2016
So adding the bits I know:
pkgutil.namespace_packagesto an explicitpackageslist or just usesetuptools.find_packages().Now, the real question is this: what happens as we switch? If someone has one of the current versions installed, and we switch over, will everything just work? (Does that ever happen?)
haberman commentedon Mar 5, 2016
Closing in favor of #1296
Remove uses of pkg_resources in non-namespace packages.
Remove uses of pkg_resources in non-namespace packages. (#7902)
Fixed: Hardened tokenize/parse, esp. comment parsing, see protocolbuf…
Other: Everything can be block- or line-style when parsing, see proto…