Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: redirect entrypoints to py_console_script_binary #2063

Open
wants to merge 13 commits into
base: main
Choose a base branch
from

Conversation

groodt
Copy link
Collaborator

@groodt groodt commented Jul 13, 2024

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 enabled auto-merge July 13, 2024 06:45
Copy link
Collaborator

@aignas aignas left a comment

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.

@@ -13,6 +13,8 @@
# limitations under the License.

load("@bazel_skylib//:bzl_library.bzl", "bzl_library")
load("@rules_python//python:defs.bzl", "py_library")
Copy link
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
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
Collaborator 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
Contributor

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
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
Collaborator 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
Contributor

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
Copy link
Collaborator

aignas commented Oct 14, 2024

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

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