-
Notifications
You must be signed in to change notification settings - Fork 540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rules_python does not respect the namespace_packages=
argument of setuptools.setup().
#93
Comments
Is anyone working on fixing this? This makes it impossible to use google-auth and protobuf in the same py_binary. |
/cc @brandjon |
+1 ran into this issue too. I think the suggested
Unfortunately I'm stuck specifically because of protobuf. Using google protos, i.e. google/api, generates the google namespace, and using the py_namespace trick is not as straight forward because I start having conflicting file complaints... I suppose if someone tries out the workaround, you could put the namespace in a separate BUILD files :(. Alas I'm out of time to try and fix it, so I'll be installing protobuf with pip on the system for now until this issue can be addressed. Though, rules_protobuf may need a similar change too... 😢. Update - I was able to verify the workaround for jarco with cherrypy:
|
@therc to use protobuf/google apis I created a fork of googleapiclient that simply removes google-auth as a strict dependency from the setup.py. It does work at the expense of using googleapiclient instead of google-cloud packages. The only real benefit of those, at the moment, is gRPC and better idioms, as far as I can see. I think this is the best approach to use python google apis with Bazel at this point in time. |
i fixed this issue in https://github.com/ali5h/rules_pip |
This issue is really blocking our adoption of bazel for Python ... |
@ali5h I tried your rules and I can't get it to work with a
I wonder if you have any ideas about this. Thanks for the contribution though! |
@skyl my implementation requires that you pin the version in |
generate your |
I'm trying to use your If you've fixed this problem, can you elucidate how you've fixed this issue, so that I can poke through your code and rip out a solution for myself 🙂 |
i just tested it and added them to the tests, it works, did you compile the reqs with pip-compile? |
Yes I did, but I may have done something else wrong. Do you mind pointing me at the relevant source code in your project to help me learn about a solution? Edit: I've got a branch here, https://github.com/thundergolfer/the-one-true-bazel-monorepo/pull/12/files, where I'm trying to get this working. I have to hack an internal |
fixed the issues, plz use latest release, thanks for the feedback |
I am using the latest git commit release of rules_python as described in #273, but get the same result: no error from Bazel, but no code loaded from the azure package. All other libraries load as expected, all versions pinned in requirements.txt. |
rules_python 0.1.0 has been released which upstreams the rules_python_external repo. Please switch from |
(more information here: http://setuptools.readthedocs.io/en/latest/setuptools.html#namespace-packages)
There are packages, that have the same namespace in their name. Trying to use them via rules_python fails on
ImportError: No module named '...'
.For example, try installing this package:
testing.postgresql
. It has another packagetesting.common.database
as its dependency. Now rules_python installs those separately without taking thenamespace_packages=['testing']
argument into account, which creates a situation where duringimport testing.postgresql
, the program fails withImportError: No module named 'testing.postgresql'
, due to it's stopping the search after finding the first "testing" directory in the path, which belongs totesting.common.database
.Possible solution: pushing an init.py file declaring a namespace (having the content:
__path__ = __import__("pkgutil").extend_path(__path__, __name__)
) instead of an empty file to folders that should be namespaces.The text was updated successfully, but these errors were encountered: