[Bazel] Fix USB dependencies, init.py creation #3098

Merged

RyanDraves merged 4 commits from bazel-2.3.0-patch into develop

2026-07-29 11:35:51 -05:00

RyanDraves commented

2026-07-24 11:57:28 -05:00

(Migrated from github.com)

The 2.3.0 release seems to depend on nonexistent target for the USB reset library. A la https://github.com/raspberrypi/picotool/pull/351, new rules_py warnings spam about the py_binary usage in the repo; these changes silence the warning.

I didn't make an issue, sorry for the hygiene.

The 2.3.0 release seems to depend on nonexistent target for the USB reset library. A la https://github.com/raspberrypi/picotool/pull/351, new `rules_py` warnings spam about the `py_binary` usage in the repo; these changes silence the warning. I didn't make an issue, sorry for the hygiene.

armandomontanez commented

2026-07-27 10:10:43 -05:00

(Migrated from github.com)

Sorry for the silence on this. I think we should definitely fix the dependency issue.

The Python warning is newly introduced in the latest version of rules Python. I think there's a path to rolling that out in a way where rules_python doesn't require this to be set on every py_test and py_bianry. Warnings like this are very noisy, I'll try to spin up a proposed rules_python rollout mechanism today.

If I can't get that out today, I'll approve this as a short-erm workaround. In the interim, I recommend early-adopting --incompatible_default_to_explicit_init_py.

Sorry for the silence on this. I think we should definitely fix the dependency issue. The Python warning is newly introduced in the latest version of rules Python. I think there's a path to rolling that out in a way where `rules_python` doesn't require this to be set on every py_test and py_bianry. Warnings like this are very noisy, I'll try to spin up a proposed rules_python rollout mechanism today. If I can't get that out today, I'll approve this as a short-erm workaround. In the interim, I recommend early-adopting `--incompatible_default_to_explicit_init_py`.

RyanDraves commented

2026-07-27 10:17:55 -05:00

(Migrated from github.com)

Thanks. I didn't have success with --incompatible_default_to_explicit_init_py with pico-sdk as a dependency, but I'll try and give it another go today as well to see if that silences it. Ironically - very ironically - I also got a ton of warning spam from rules_py's py_binary's involved in the build process. Ugh.

Thanks. I didn't have success with `--incompatible_default_to_explicit_init_py` with `pico-sdk` as a dependency, but I'll try and give it another go today as well to see if that silences it. Ironically - very ironically - I also got a ton of warning spam from `rules_py`'s `py_binary`'s involved in the build process. Ugh.

RyanDraves commented

2026-07-27 15:02:35 -05:00

(Migrated from github.com)

Thanks. I didn't have success with --incompatible_default_to_explicit_init_py with pico-sdk as a dependency, but I'll try and give it another go today as well to see if that silences it. Ironically - very ironically - I also got a ton of warning spam from rules_py's py_binary's involved in the build process. Ugh.

I was mistaken; common --incompatible_default_to_explicit_init_py does indeed silence the warnings. Totally fair to not make the spam your problem if you just want the dependency fix.

> Thanks. I didn't have success with `--incompatible_default_to_explicit_init_py` with `pico-sdk` as a dependency, but I'll try and give it another go today as well to see if that silences it. Ironically - very ironically - I also got a ton of warning spam from `rules_py`'s `py_binary`'s involved in the build process. Ugh. I was mistaken; `common --incompatible_default_to_explicit_init_py` does indeed silence the warnings. Totally fair to not make the spam your problem if you just want the dependency fix.

kilograham commented

2026-07-27 15:28:00 -05:00

(Migrated from github.com)

I'm going to merge this as is since i'm not sure what common --incompatible_default_to_explicit_init_py means ;-)

feel free to add another PR to fix up

I'm going to merge this as is since i'm not sure what `common --incompatible_default_to_explicit_init_py ` means ;-) feel free to add another PR to fix up

lurch commented

2026-07-28 02:44:47 -05:00

(Migrated from github.com)

The Bazel "buildifier" check is also causing the CI to fail on this PR...

RyanDraves commented

2026-07-28 08:47:18 -05:00

(Migrated from github.com)

The Bazel "buildifier" check is also causing the CI to fail on this PR...

My bad. Could I interest y'all in a bazel_env setup in another PR?

> The Bazel "buildifier" check is also causing the CI to fail on this PR... My bad. Could I interest y'all in a [bazel_env](https://aspect.build/blog/bazel-devenv) setup in another PR?

kilograham (Migrated from github.com) approved these changes

2026-07-29 11:35:40 -05:00

armandomontanez commented

2026-08-03 19:08:18 -05:00

(Migrated from github.com)