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

[bzlmod bug/regression] entry_point no longer working with blzmod #958

Closed
xinbinhuang opened this issue Jan 1, 2023 · 5 comments · Fixed by #1220
Closed

[bzlmod bug/regression] entry_point no longer working with blzmod #958

xinbinhuang opened this issue Jan 1, 2023 · 5 comments · Fixed by #1220

Comments

@xinbinhuang
Copy link

xinbinhuang commented Jan 1, 2023

🐞 bug report

Affected Rule

The issue is caused by the rule:

entry_point when using with blzmod

Is this a regression?

Yes

Description

entry_point rule no longer working when used with blzmod

🔬 Minimal Reproduction

You can find a reproducible example at this repo: https://github.com/xinbinhuang/rules_python_bug

🔥 Exception or Error

~ $ bazel run "//:flake8"    
ERROR: /workspace/BUILD.bazel:3:6: no such package '@[unknown repo 'pip_flake8' requested from @]//': The repository '@[unknown repo 'pip_flake8' requested from @]' could not be resolved: No repository visible as '@pip_flake8' from main repository and referenced by '//:flake8'
ERROR: Analysis of target '//:flake8' failed; build aborted: Analysis failed
INFO: Elapsed time: 4.436s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (1 packages loaded, 0 targets configured)
ERROR: Build failed. Not running target

🌍 Your Environment

Operating System:

  
mac/linux
  

Output of bazel version:

  
6.0.0
  

Rules_python version:

  
0.16.1
  

Anything else relevant?

@xinbinhuang xinbinhuang changed the title [bzlmod] entry_point no longer working with blzmod [bzlmod bug/regression] entry_point no longer working with blzmod Jan 1, 2023
@keith
Copy link
Member

keith commented Jan 4, 2023

Same here, our case is even just registering pre-commit as a dep seems to get dropped

@keith
Copy link
Member

keith commented Jan 18, 2023

my case was fixed at head with 2c29f40, but based on that commit it's because my case had a - and yours doesn't, so maybe it's different. have you tried with HEAD?

@xinbinhuang
Copy link
Author

xinbinhuang commented Jan 18, 2023

my case was fixed at head with 2c29f40, but based on that commit it's because my case had a - and yours doesn't, so maybe it's different. have you tried with HEAD?

Yeah, I've encountered that with another package and fixed it with the commit. But this's a different issue I think.

aignas added a commit to aignas/rules_python that referenced this issue Apr 30, 2023
* Added support for users setting `incompatible_generate_aliases` to
  `True`. They can use the `bin` struct exposed via
  `@<hub_rep>//<dep>:bin.bzl`.
* Added support for bzlmod users not setting
  `incompatible_generate_aliases`. They can use it via
  `use_repo("<hub_repo>_<dep")` and then importing the same struct via
  `@<hub_repo>_<dep>//:bin.bzl`.
* The legacy behaviour of the `entry_point` macro is unchanged for the
  remaining users.

Design notes:
* Expose the struct in separate `.bzl` files in order to have no eager
  fetches.
* Exposing it via a struct will give users an error message if the
  target with the specified name does not exist and it will tell the
  available struct attributes.
* The inspiration comes from `rules_js` which @alexeagle has pointed to.

Fixes bazelbuild#958.
aignas added a commit to aignas/rules_python that referenced this issue May 4, 2023
* Added support for users setting `incompatible_generate_aliases` to
  `True`. They can use the `bin` struct exposed via
  `@<hub_rep>//<dep>:bin.bzl`.
* Added support for bzlmod users not setting
  `incompatible_generate_aliases`. They can use it via
  `use_repo("<hub_repo>_<dep")` and then importing the same struct via
  `@<hub_repo>_<dep>//:bin.bzl`.
* The legacy behaviour of the `entry_point` macro is unchanged for the
  remaining users.

Design notes:
* Expose the struct in separate `.bzl` files in order to have no eager
  fetches.
* Exposing it via a struct will give users an error message if the
  target with the specified name does not exist and it will tell the
  available struct attributes.
* The inspiration comes from `rules_js` which @alexeagle has pointed to.

Fixes bazelbuild#958.
rickeylev pushed a commit that referenced this issue May 4, 2023
…po (#1206)

It seems that the tool was correctly trying to modify the `.bazelrc` at
the
root of the repo, but the `find` execution would run in the `$PWD`. This
change ensures that the `find` is consistent with the file we are trying
to modify and allows the user to execute the script from anywhere in the
repo.

Tested:
1. Update the deleted packages with the version of the script at HEAD
1. Fix the bug
1. Rerun the script from the 'tests' sub-folder in the repo to ensure
that
   running the script is noop.
1. Revert the changes to '.bazelrc' to reduce conflicts as other PRs are
   modifying it.

Work towards #958.
rickeylev pushed a commit that referenced this issue May 14, 2023
Previously we would depend on the value of .bazelrc and this
change ensures that we are explicitly enable bzlmod via CLI
args. It seems that the `py_proto_library` integration tests
defined in the `//examples:BUILD.bazel` file were not running
using `bzlmod` before hand, however, they were correctly
executed in the CI.

Work towards #958.
@chrislovecnm
Copy link
Collaborator

@aignas is this fixed?

@aignas
Copy link
Collaborator

aignas commented May 17, 2023

Fixed by #1220.

chrislovecnm pushed a commit that referenced this issue May 18, 2023
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants