[Design Doc] Customizing the Python Stub Template

[Jon Brandvein]

Users have expressed some interest in overriding the template that py_binary uses to generate its stub script. This design doc proposes a way to do that. See the discussion thread here.

It's not clear to me why we even need this, and I'm worried it might expose too much detail. So if you have a use case where you'd want to inject custom logic into the stub, we'd like to hear it.

[ai...@google.com]

It's not clear to me why we even need this, and I'm worried it might expose too much detail. So if you have a use case where you'd want to inject custom logic into the stub, we'd like to hear it.

You hinted at why we would want this:

However, the author believes that the stub is more naturally tied to the Python interpreter than to an individual target. Putting the attribute on py_runtime makes it easy to affect all Python targets that use the same interpreter. It also allows the same Python target to use different stubs depending on which interpreter it is built for -- for instance, the same target can have different stubs on different platforms.

This allows you to experiment with a new python runtime and adjust the template for that.

[Jon Brandvein]

I'm not sure what you mean. That paragraph was about how you might theoretically have two Python runtimes that require totally different templates. The thing is, I don't know an example of a difference in runtimes that is so drastic as to motivate having a whole new template, rather than just substituting different values into the same template. That's what I'm hoping to get from this discussion, or else conclude that we don't need such a powerful feature.

If you mean that we can use the template to invoke different Python interpreters, well, yes, but mucking with the template is a pretty low-level way to do that compared to using toolchains. :)

--
You received this message because you are subscribed to the Google Groups "Bazel/Python Special Interest Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-sig-pyth...@googlegroups.com.
To post to this group, send email to bazel-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-sig-python/6efa89e0-4851-429e-b283-6117851d6fbb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[cmoore]

I think that sounds great!  Considering my recent battles with code coverage and Bazel, anything like that pulled from the binary should be made configurable.  It's not acceptable to fork Bazel or wait until upstream gets around to fixing something when users hit a simple bug in one of those templates.  Locally experimenting with replacements and bug fixes accomplishes a lot, namely it enables users to tackle problems that they prioritize differently than upstream and it enables them to easily experiment to suggest new features, fixes, etc..

In the context of Python code coverage, it would be great to change the template for that use case.  I'm not aware of a better alternative at the moment.

[Jon Brandvein]

Thanks for sharing your use case. I take it you're not strongly opposed to the customization being on py_runtime as opposed to py_binary, provided that you still (in the future) get to control which py_runtime a given binary uses?