package rules should create wrappers around tool entry_points

[alexeagle]

This feature is inspired by how we handle the ecosystem of tools in rules_nodejs.

For a long time we assumed we needed to write custom rules for each tool in the ecosystem. The last one of these was for the Less CSS preprocessor. Then we realized that since we have Starlark code generating BUILD files to dep on each installed package (via pip_install for example, but will apply for poetry or others), we could also generate .bzl files to call tools. Now every tool in npm ecosystem can be called from Bazel (I wrote more about it )

For example if I pip_install the package Sphinx==3.1.1 then today I can load("@my_deps//:requirements.bzl", "requirement") and dep on requirement("sphinx") - but loading sphinx as a dep is not the common way to use it. It's a utility for generating documentation so it should be called as a separate action, without me writing a custom program to drive it.

This is evident from the package metadata

% less $HOME/.pyenv/versions/3.6.5/lib/python3.6/site-packages/Sphinx-3.1.1.dist-info/entry_points.txt
[console_scripts]
sphinx-build = sphinx.cmd.build:main

So users actually want to do something like this:

load("@my_deps//sphinx:defs.bzl", "sphinx_build")

sphinx_build(
    name = "docgen",
    srcs = glob(["docs/**"]),
    args = ["-b", "html", "$(@D)"],
    outdir = "html",
)

Similarly it should be possible to grab a server from pypi and bazel run it, or a testing framework and bazel test it. So in rules_nodejs we actually generate three things in the generated .bzl for any package that exposes entry points.

[thundergolfer]

Closely related issues

https://github.com/bazelbuild/rules_python/issues/318 and https://github.com/bazelbuild/rules_python/issues/288

also

https://github.com/dillon-giacoppo/rules_python_external/issues/18 and https://github.com/dillon-giacoppo/rules_python_external/issues/47

---

Happy to make this the parent and close the others.

So in rules_nodejs we actually generate three things in the generated .bzl for any package that exposes entry points.

What are those 3 things? Do you generate something for bazel test even if it isn't needed (say for a server)?

[alexeagle]

This golden file from one of our tests illustrates the three things: https://github.com/bazelbuild/rules_nodejs/blob/1.x/internal/npm_install/test/golden/jasmine/index.bzl.golden yes we always generate them because there's nothing in the metadata of an npm package that tells you whether a binary is meant to produce outputs, be a long-running process, or be a test runner. So we just adapt the behavior based on how the user names/uses the loaded symbol.

[UebelAndre]

Would this mean the entry points would be represented by py_binary targets? 🙏

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 180 days. It will be closed if no further activity occurs in 30 days. Collaborators can add an assignee to keep this open indefinitely. Thanks for your contributions to rules_python!

[UebelAndre]

Anyone have any new thoughts on this one? I feel like it'd solve for a sizable gap in functionality and unlock many workflows.

[UebelAndre]

I ended up writing a rule which solves for my specific use case. Hopefully others can find it useful or become inspired to adapt it to something worth merging 😄

https://github.com/UebelAndre/bazel_pip_entrypoint

[alexeagle]

Note, this was solved for the bazel run case by #523 which adds a generated py_binary for every bin.

We still need the bazel test and bazel build cases to be contributed, where a py_test and genrule target are generated, respectively.