Discuss how the venv layout could facilitate entry points

[aignas]

Currently the py_console_script_binary is building a full runfiles tree and for the usecase that you are implementing in here - a py_binary is just calling utilities within the same venv that is a little bit too heavy. I want to separate the usecases for py_console_script_binary to be only something where we actually want to build a full separate venv for the said scripts.

Ah, I think I get what you mean. Do you want to file an issue for further discussion? entrypoints/scripts/things-in-bin seem distinct enough they warrant something in a provider, but it's not clear to me how a consumer can make effective use of it via a py_binary.

Originally posted by @rickeylev in #3743 (comment)

[rickeylev]

I want to separate the usecases for py_console_script_binary to be only something where we actually want to build a full separate venv for the said scripts.

I agree. That said, it's not quite up to us. The contract of py_console_script_binary is it gives you an executable target, and bazel always gives executable targets their own runfiles tree.

entrypoints/scripts/things-in-bin seem distinct enough they warrant something in a provider, but its not clear to me what

For posterity/edification, the gist of the change I made to whl_library is the py_library it defines just returns PyInfo.venv_symlinks with a value like kind=BIN file=bin/foo, where bin/foo is just a generated file with the typical entry point startup code.

My point being, if one wanted a "light weight" or "same venv" py_console_script_binary, then all one has to do is (1) have a rule generate the entry point file, (2) return it in PyInfo.venv_symlinks as a kind=BIN, (3) add it to the deps (direct or transitive) of a py_binary.

If one wanted a "medium" weight or "can specified its own deps" version that pulled in additional dependencies, then just add the relevant deps to the py_library returning the kind=BIN.

---

Is part of the thinking: make py_console_script_binary re-use the entry point file that py_binary wires into a venv (as generated by what whl_library does)? I suppose that's possible. I guess if e.g. @pypi//pylint:pkg had a provider with a field entry_points: dict[str name, File file] ? And then it can just lookup the particular file for the name of interest.