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	1c20f5b
🔍 Latest deploy log	https://app.netlify.com/sites/nifty-bassi-e26446/deploys/666042ad0ccf6b000805daf4
😎 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

[mmorel-35]

@phlax,
I believe this can be merged.
Bzlmod is not activated here

[phlax]

lgtm, with one question - thanks @mmorel-35

[phlax]

is the lockfile not checked in to repo?

[mmorel-35]

Because it isn't useful to share it as it is plateform dependant

[phlax]

hmm - i thought the utilitiy was that it contains the hashes (ie ensures you are downloading exactly the same file/s)

i seem to remember a similar issue with python lockfiles (which are generally checked in)

[mmorel-35]

Even if the docs says it's better to persist it. You'll see many BCR maintainers discouraging it's persistance

[phlax]

yeah the docs seem to suggest this should be checked in afaict (https://bazel.build/external/lockfile#merge-conflicts)

i think we will need to do this - we cant just ensure trust/reproducibility from just versions