chore(bazel): add MODULE.bazel files for bzlmod

[mmorel-35]

Signed-off-by: Matthieu MOREL matthieu.morel35@gmail.com

[netlify]

✅ Deploy Preview for nifty-bassi-e26446 ready!

Name	Link
🔨 Latest commit	ec5cf79
🔍 Latest deploy log	https://app.netlify.com/sites/nifty-bassi-e26446/deploys/65e3320e6a0a0b0008f94fcb
😎 Deploy Preview	https://deploy-preview-1802--nifty-bassi-e26446.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[mmorel-35]

I'm trying to introduce bzlmod here but Package 'website/tools/pelican' is failing because of the use of entry_point.

I'm seeing this :

fail("""Please replace this instance of entry_point with the following:
Error in fail: Please replace this instance of entry_point with the following:

load("@rules_python//python/entry_points:py_console_script_binary.bzl", "py_console_script_binary")

py_console_script_binary(
    name = "pelican",
    pkg = "@website_pip3//pelican",
    script = "pelican",
)

[phlax]

arggh - i wrote some feedback but it seems github stole it 8(

thanks for working on this

im not so familiar with bzlmod, so need to do a bit of testing

wondering if we lose the dep shas in this PR

[mmorel-35]

I believe it would be better to start by updating rules_python and migrate from entry_point to py_console_script_binary and then migrate to bzlmod.

WDYT ?

wondering if we lose the dep shas in this PR

I don't it's a good idea. As Envoy is depending on toolshed it will need to migrate to bzlmod to use toolshed as a bazel_dep.
Once it's done you'll be able to remove the old way of dependency management

[phlax]

... start by updating rules_python and migrate from entry_point to py_console_script_binary ...

sounds like a good idea - i think rules_python is up to date already - at least in envoy

I don't it's a good idea.

not sure im following here

[mmorel-35]

not sure im following here

Envoy depends on toolshed but still uses the old way of handling dependencies so you cannot remove the old way in toolshed until envoy uses bzlmod to use toolshed as a bazel_dep

[phlax]

... you cannot remove the old way in toolshed until envoy uses bzlmod to use toolshed as a bazel_dep

i got that bit - just wasnt understanding response to question about not having shasums

[mmorel-35]

You won't have any shasum, just the name of the dep and it's version with, something like that :

bazel_dep(name = "dep_name", version = "1.0.0", repo_name  = "my_repo_dep_name")

[phlax]

You won't have any shasum

k - so trying to get up to speed here - does this mean sha resolution/evaluation is done in the lock file and end users no longer are expected to manually set these etc ?

[mmorel-35]

It means that they won't need to maintain the shasum themselves, everything is going to be handled in the BCR

[phlax]

lmk when this is ready to land - excited to get started with this