Skip to content

fix: redirect entrypoints to py_console_script_binary#2063

Closed
groodt wants to merge 13 commits into
mainfrom
groodt-entrypoints-pypi
Closed

fix: redirect entrypoints to py_console_script_binary#2063
groodt wants to merge 13 commits into
mainfrom
groodt-entrypoints-pypi

Conversation

@groodt

@groodt groodt commented Jul 13, 2024

Copy link
Copy Markdown
Contributor

entrypoints (originally from setuptools) AKA console_scripts (as defined in pyproject.toml) AKA py_console_scripts (as defined in rules_python) are a packaging standard.

It therefore makes sense to package this code alongside the other packaging rules code and not the python language rules code. The packaging rules code currently sits inside pypi. Looking at the code, we can see that it is packaging related because it extracts the contents of .dist-info directories, which originate from built distributions (wheels).

@groodt groodt changed the title WIP fix: redirect entrypoints to py_console_script_binary fix: redirect entrypoints to py_console_script_binary Jul 13, 2024
@groodt groodt marked this pull request as ready for review July 13, 2024 06:44
@groodt groodt requested review from aignas and rickeylev as code owners July 13, 2024 06:44
@groodt groodt enabled auto-merge July 13, 2024 06:45

@aignas aignas left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, not against moving this under private/pypi, but I am not sure if having a single pip.bzl file where we are loading everything from is great. Having a separate file per macro/function allows for much better isolation and cache hits.

What is more, this is a build rule and quite a few things in the pip.bzl are repo rules, except for the compile requirements.

# limitations under the License.

load("@bazel_skylib//:bzl_library.bzl", "bzl_library")
load("@rules_python//python:defs.bzl", "py_library")

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please drop rules_python in the load statements in internal code.


def _compatibility_shim(**kwargs):
# buildifier: disable=print
print("Please use `py_console_script_binary` from `//python:pip_bzl` instead.")

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I saw people using deprecation attribute in some cases instead of a print (this is in py_proto_library case). That may be less spammy, as this will cause one print invocation per usage of the rule, I think?

Maybe it would be useful to print a buildozer command for replacing the loads?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM. Didn't know about it. Will FIXUP.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For macros, I think there's a doc string syntax that stardoc parses out into a "deprecation" doc text. I think it's either """DEPRECATED: blabla """ or """[DEPRECATED]: blalba""" ? Not entirely sure.

I'm pretty sure our docgen respects it when stardoc emits it.


```{include} /_includes/py_console_script_binary.md
```
Please use `py_console_script_binary` from `//python:pip_bzl` instead.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit, I think this should be pip.bzl instead of pip_bzl.

Maybe it would be great to write the full load statement to help users?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM. Will FIXUP.

@rickeylev

Copy link
Copy Markdown
Collaborator

Yeah, I'll echo much of what Ignas said:

  • Don't have kitchen sink bzl files. Over time, it incurs more unused loads.
  • The above is especially true for the repo/loading/analysis phases. We want to avoid the repo-rule phase and loading-phases from causing loads of the other's code.

I'm -1 on moving the public symbol simply because it seems like needless churn. I guess if you really want to move it, OK. But I think we should keep the old location around for longer than typical because people are still upgrading from workspace->bzlmod, and if they don't have a stable load() path for the entry point replacements, it'll be pretty annoying to go through upgrading.

I'm fine with moving the implementation under python/private/pypi.

@aignas

aignas commented Oct 14, 2024

Copy link
Copy Markdown
Collaborator

@groodt, do you plan (have time) to clean this up before 1.0?

@aignas

aignas commented Jul 6, 2026

Copy link
Copy Markdown
Collaborator

This is essentially done. Entry point code got removed.

@aignas aignas closed this Jul 6, 2026
auto-merge was automatically disabled July 6, 2026 07:35

Pull request was closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants