python-gflags is not Python 3 compatible
See original GitHub issueDescription of the problem:
See the last post in #3065 - the pkg_tar rule depends on the python-gflags (included in the Bazel repo), which is not py3 compatible and fails with a syntax error on my system. According to https://github.com/google/python-gflags/issues/20 (the error report to the syntax error I get) the argparse standard library should be preferred. The current version of gflags however seems to be py3 compatible, so an update might be worth investigating.
If possible, provide a minimal example to reproduce the problem:
load(“@bazel_tools//tools/build_defs/pkg:pkg.bzl”, “pkg_tar”)
Then run any BUILD file with a pgk_tar rule on Arch Linux (or any other distro that sets /usr/bin/python to python3)
Environment info
-
Operating System: Linux
-
Bazel version (output of
bazel info release
): release 0.5.0- (@non-git) -
If
bazel info release
returns “development version” or “(@non-git)”, please tell us what source tree you compiled Bazel from; git commit hash is appreciated (git rev-parse HEAD
): Arch Linux upstream package (https://www.archlinux.org/packages/community/x86_64/bazel/download/)
Have you found anything relevant by searching the web?
https://github.com/bazelbuild/bazel/search?q=from+third_party.py+import+gflags shows that it is only used in 16 files (2 of the results are duds).
I think it might be possible to remove or replace gflags 2.0 entirely from Bazel. I am not so sure if gflags 3.x should be used to replace it (it is not very well documented imho, but Google employees might be more used to writing code with it?) or if plain argparse might be a better choice. Gflags seems to be used by other languages (e.g. Java) too, so a common standard might be still desirable.
Another option might be to patch the few issues in https://github.com/bazelbuild/bazel/blob/master/third_party/py/gflags/__init__.py (https://github.com/bazelbuild/bazel/blob/master/third_party/py/gflags/BUILD claims that it is PY2AND3 compatible after all) - a few “except Foo as e” instead of “except Foo, e” and importing print_function from future are probably all it takes to make it work. This approach would break Python compatibility below 2.6, I am not sure if this is good or bad for your use case. There might be already some other libraries that also require more recent versions (…but is Python2 recent at all?).
Anything else, information or logs or outputs that would be helpful?
(If they are large, please upload as attachment or provide link).
This really should have been caught by some kind of test that takes a look at py_library rules with srcs_version tags and verifies that these are actually correct:
$ python -m py_compile foo.py
File "foo.py", line 1091
except gflags_validators.Error, e:
^
SyntaxError: invalid syntax
$ python2 -m py_compile foo.py
$
Issue Analytics
- State:
- Created 6 years ago
- Comments:11 (10 by maintainers)
Both code reviews have been merged, closing.
The correct thing to do here is move off of gflags entirely, not carry your own copy of the ancient dead code at all. Use absl.flags from https://pypi.org/project/absl-py/.