[thundergolfer]

For those using Bazel this looks like a pretty helpful example of developing and releasing a cross-platform Python package with native-libs (C++ in this case).

I've wondered for a while how Deepmind manages their (Python & C++) codebase. This is a small window into that I think, and you can see that they're likely using internal 'Blaze' Python rules and rely on the maintenance of compatibility with the open-source Bazel rules. `py_library` is used in `tree/BUILD`, but it is not loaded explicitly as is expected with Bazel these days; the rule definition is loaded by Bazel implicitly.

[orbifold]

Combining C++ with python via pybind is something bazel really excels at, with CMake you end up maintaining two disjoint build and packaging systems.

[pyentropy]

My project builds 20 binary wheels supporting most platforms except ARM (todo): https://pypi.org/project/elkai/#files It's one line of code using CMake. [1]

Granted, you also need CI that has most Python versions/platforms and the Python CMake extension by scikit team too. Ex. MacOS Travis with brew [2]

[1] https://github.com/filipArena/elkai/blob/ef8ee98d8114240b204...

[2] https://github.com/filipArena/elkai/blob/master/.travis.yml

[jeffbee]

I thought implicitly doing anything is against the whole bazel philosophy.

[dimator]

You're right, this is likely to require an explicit load in the future, iirc. As for now, the py_* rules are so common that they are implicit. Loading replacement py_* rules overrides the built-in.