search

TriggerMail / rules_pyz

Bazel Python rules that package everything in an executable zip
Apache License 2.0
29 stars 19 forks source link

Does not have mandatory providers: 'PyZProvider' #33

Open Globegitter opened 6 years ago

Globegitter commented 6 years ago

Hi just trying out these rules and running into an issue with local wheels. I am getting

(14:30:51) ERROR: /somepath/third_party/pypi/py3/BUILD.bazel:2:1: in deps attribute of pyz_library rule //third_party/pypi/py3:ipaddress: '//third_party/pypi/py3:py3_ipaddress' does not have mandatory providers: 'PyZProvider'. Since this rule was created by the macro 'pypi_libraries', the error might have been caused by the macro implementation in /somepath/third_party/pypi/py3/rules.bzl:241:14
(14:30:52) ERROR: Analysis of target '@workspace//:manage' failed; build aborted: Analysis of target '//third_party/pypi/py3:ipaddress' failed; build aborted

This error makes sense as the local wheels are a filegroup but are added as a dependency to pyz_library - but not sure what the intendend behaviour is. I suppose there should be something extracting the wheels and adding a pyz_library for it no?

evanj commented 6 years ago

Which bazel version are you using? This can happen when the WORKSPACE was not imported with the correct global name. What does your git_repository rule look like in your WORKSPACE file?

Globegitter commented 6 years ago

I am using 0.17 rc1. I'll take a look again in a few days.

evanj commented 6 years ago

Thanks! Figuring out how to reproduce the issue is probably the biggest issue. Make sure you are importing it as @com_bluecore_rules_pyz.

dforsyth commented 6 years ago

I've run into this also, and I'm sure I'm importing as @com_bluecore_rules_pyz.

I'm using bazel 0.16.1 on CentOS 7. I've tried going back to the initial change that added local wheel support and still run into the same issue, so it's not particularly clear how this is supposed to work. Is there a minimal example of a repo using local wheels available somewhere?

snifi commented 6 years ago

I see the same problem. I set up a repo for reproducing the problem in https://github.com/snifi/Failed-pyz_rules.

Due to my understanding in the generated file the issue is in line 25 + 26: the native.filegroup defined in line 30ff is not a PyZProvider according to definition anymore and thus according to https://github.com/TriggerMail/rules_pyz/blob/master/rules_python_zip/rules_python_zip.bzl Line 15 can't be a "deps" but must be a "wheels"

Updating this to: deps=[ ], wheels=[":pypi_markupsafe"], and moving the wheels folder to be subfolder of ./third_party/pypi/ finally solves the problems (see third commit https://github.com/snifi/Failed-pyz_rules/commit/9849f0663da531c7ddd9a52b7c2f04c97a69446f) Can you confirm this and maybe help me how to solve the problem (without manual steps being involved)?

apt-itude commented 6 years ago

@snifi did you test that fix with any actual pyz_* targets that depend on the markupsafe library? I did what you suggested and got myself to the point where my library builds, but then I get import errors when I actually run my test. Taking a look at the test_exe_exedir, all third-party libraries that are local wheels are missing.

Does anyone have a working example with local wheels?