feat(bzlmod): support entry_point macro

[aignas]

Add entry_point macro to the repo generated by the pip.parse extension.
This works by using the canonical label literal, so should work without users
needing to add the spoke repos to the use_repo statement. We test this by
having an extra folder in the bzlmod example.

Fixes #958.

[aignas]

@rickeylev, I like this approach better than #1189 at least for now, because it does not require users to eagerly fetch the repo just to access the entrypoint struct as the label for the entrypoint in this PR is constructed from the hub repo macro without any imports from the spoke repos.

This means that the users wanting to use the entry_point have to add an extra use_repo statement, but it may be a good enough trade-off here.

The rough edges that I found when porting a test from the //examples/pip_parse to bzlmod:
1. I could not import runfiles library if I depend on the @rules_python//python/runfiles under bzlmod. It seems to me that it could be because in the runfiles directory the rules_python exists as rules_python~override and our python import machinery is not repo mapping aware.
2. The py_test_with_transition does not work with $(location :yamllint) and I am not sure exactly why.

Should we raise a ticket for 1. in the bazel repo and 2. is a non-issue if 1. works and we are using the runfiles library?

EDIT: it seems that whilst rules_python.python.runfiles import does not work, python.runfiles import does work and I remembered that there was a discussion when the runfiles examples was being contributed. So my complaint is non-existent.

[aignas]

Switched to $(rlocationpath and everything started working, ready for the final review.

[alexeagle]

This seems reasonable to me. FYI @fmeum as a subject matter expert here, in case there's some way to avoid the use_repo I'm not thinking of.

[alexeagle]

Suggested change

	"pip_yamllint",
	# The 'entry_point' macro will expand to reference this repository in "userspace",
	# so we have to declare that usage for bzlmod's strict repository visibility.
	"pip_yamllint",

[fmeum]

bazel test //... in examples/bzlmod passes for me if I just delete it. The only reference is a canonical label literal, which doesn't require a use_repo.

[fmeum]

bazel test //... in examples/bzlmod passes for me if I just delete it. The only reference is a canonical label literal, which doesn't require a use_repo.

[aignas]

As @fmeum suggested, it seems that we can avoid the use_repo here and the example just works without it. Learned something new about how bzlmod works.

@fmeum, your last comment about the %%FRIENDLY_NAME%% works only if we have the use_repo statement, right? If the instructions to users are that they should not need to add additional use_repo statements, then the code should be good as is, right?

[fmeum]

@fmeum, your last comment about the %%FRIENDLY_NAME%% works only if we have the use_repo statement, right? If the instructions to users are that they should not need to add additional use_repo statements, then the code should be good as is, right?

Every repo created by a module extension can see all other repositories created by the extension without any use_repos. If you return Label("@%%FRIENDLY_NAME%%...), that should also work. The currently approach looks alright too, so there is not need to change it.

[rickeylev]

Mostly LGTM. Just need to update to head to reflect Chris's recent changes to how to setup bzlmod stuff.

[aignas]

@rickeylev, the build is fixed, so should be ready to be merged.

[aignas]

Squashed everything into a single commit and rebased on the current main. Tested the example with:

$ bazel test ...
Starting local Bazel server and connecting to it...
INFO: Analyzed 62 targets (121 packages loaded, 5685 targets configured).
INFO: Found 55 targets and 7 test targets...
WARNING: cleared convenience symlink(s) bazel-bin, bazel-testlogs because their destinations would be ambiguous
INFO: Elapsed time: 67.466s, Critical Path: 10.95s
INFO: 90 processes: 26 internal, 62 darwin-sandbox, 2 local.
INFO: Build completed successfully, 90 total actions
//:all_requirements                                                      PASSED in 0.8s
//:all_wheels                                                            PASSED in 0.3s
//:requirements_test                                                     PASSED in 10.1s
//:test                                                                  PASSED in 1.1s
//:test_with_transition                                                  PASSED in 1.4s
//entry_point:entry_point_test                                           PASSED in 2.5s
//runfiles:runfiles_test                                                 PASSED in 1.4s

Executed 7 out of 7 tests: 7 tests pass.
There were tests whose specified size is too big. Use the --test_verbose_timeout_warnings command line option to see which ones these are.